Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.
Mats, and others, Le 17 févr. 2017 à 17:38, Karl Dubost a écrit : > TLDR: removing -moz-appearance will break some sites. At least Japan airlines. Let me rephrase this in a way which is more interesting for the Web compatibility stand point of view. SHIP: OK! -appearance: none -webkit-appearance: none UNSHIP: OK with a condition. -moz-appearance: none If I check carefully the way the site are currently dropping the arrows on the select/option widget is by having -webkit-appearance: button or -webkit-appearance: none. For compatibility we would need this at the same time we unship -moz-appearance: none -webkit-appearance: button -moz-appearance: button appearance: button -webkit-appearance: button and -moz-appearance: button behaves differently. See the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1246836 I created a test. http://www.la-grange.net/2017/02/21/appearance/appearance-test-0001.html The issue is that when we set -moz-appearance: button we get a widget with arrows while -webkit-appearance: button deliver a simple button. So if the site does: -webkit-appearance: button; -moz-appearance: button; background: The rendering looks broken in Firefox. and if the site does: -webkit-appearance: button; -moz-appearance: none; appearance: button background: the site will be broken if we unship -moz-appearance: none -- Karl Dubost, mozilla 💡 Webcompat http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Recommendation: please disable uBlock Origin on Searchfox, DXR
Hi everyone, I did some profiling today to find ways to improve how quickly pages load in Searchfox. One of the biggest gains I found was to turn off uBlock Origin. Disabling it shaves about a second off the load time of both Searchfox and DXR when loading nsGlobalWindow.cpp. It seems that uBlock looks for all elements that have either an id or class attribute on them and then does some processing on those nodes. Both Searchfox and DXR have a *lot* of nodes like that. To turn off uBlock for a particular site: visit the site, click on the uBlock icon in the toolbar, and then click on the big "power" button. It should turn gray. I don't know if other ad blockers have similar problems. I think AdBlock Plus works differently, but I haven't tested. And in case anyone is wondering: Searchfox doesn't include any advertising, tracking, or analytics scripts. I'm pretty certain that DXR doesn't either. -Bill ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Event.timeStamp as DOMHighResTimeStamp
As of Firefox 54, I intend to turn on, by default, the code that makes Event.timeStamp a DOMHighResTimeStamp. This makes this member a double whose value is the number of milliseconds since the time origin. This has been developed behind the dom.event.highrestimestamp.enabled preference. This preference has been set to true on Windows for Nightly/DevEdition for nearly 3 years, similarly on Linux for 1.5 years, on Mac since last December, and on Android since today. It is disabled on beta/release for all platforms, however. Chrome have shipped this since April last year. There were compatibility concerns at the time but Chrome have continued shipping this and it appears that Edge are considering making this change, and WebKit might if either Gecko or Edge ship this[1]. (The original work on this goes back to bug 77992 which I believe predates our "Intent to implement" practice so there is no intent to implement mail to point to.) Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1026804 Link to standard: I believe Anne is waiting on a second browser to ship this change before updating the DOM spec: [2] [1] https://github.com/whatwg/dom/issues/23#issuecomment-249319401 [2] https://github.com/whatwg/dom/issues/23#issuecomment-212815896 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Doxygen output?
My short (<2yr) experience of the code gave me the impression that only a small amount of it has proper doxygen comments. We must be frequenting different circles; or I'm somehow blind to them. :-) Anyway, they're mainly useful when generated websites/documents are readily available, which it seems isn't the case (anymore). So I'm guessing people don't care to write/maintain them, because there is no obvious benefit at the moment. I personally would welcome a push to make doxygen more official, at the very least for headers that get used between modules, but the more the better; and to have an official (or de-facto) generated website. -- Gerald On Monday, February 20, 2017 at 6:06:40 PM UTC+11, Henri Sivonen wrote: > Our comments mostly try to follow the Doxygen format, and MDN says > that the documentation team has a tool for importing Doxygen-formatted > IDL comments into MDN articles. > > Other than that, is Doxygen output from m-c input being published anywhere? > > https://people-mozilla.org/~bgirard/doxygen/gfx/ is 404 these days. > > -- > Henri Sivonen > hsiv...@hsivonen.fi > https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should &&/|| really be at the end of lines?
On Sun, Feb 19, 2017 at 8:07 PM, Martin Thomson wrote: > On Mon, Feb 20, 2017 at 3:18 AM, smaug wrote: > > I don't care too much about &&/|| coding style, though the current style > > does feel easier to > > read, per the reasoning dmajor gave. > > I suspect that a lot of people think this way. While it's tempting to > suggest that arguments like "that's the way I've always done it" are > bogus, there's a value in maintaining the current set of wiring in > your brain. I've learned to eyeball code pretty quickly over time and > changing layout risks reducing my efficiency. > > I don't know if there's a material difference in this case, and like > smaug, I don't feel passionately about this. Absent good evidence > that we're losing somehow, there is always at least some value in > retaining the current practice. > +1. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Doxygen output?
Not being kept up to date as far as I know. My extraction is four years out of date (e.g., https://people-mozilla.org/~msreckovic/Extracted/MozillaCentral/html/annotated.html) and as you noted, Benoit's page is no longer. The code used to create it is here: https://github.com/bgirard/doxygen-mozilla On 20-Feb-17 2:05, Henri Sivonen wrote: Our comments mostly try to follow the Doxygen format, and MDN says that the documentation team has a tool for importing Doxygen-formatted IDL comments into MDN articles. Other than that, is Doxygen output from m-c input being published anywhere? https://people-mozilla.org/~bgirard/doxygen/gfx/ is 404 these days. -- - Milan (mi...@mozilla.com) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to remove: support for installing multiple xpis simultaneously
On 2/18/17 7:40 AM, bird.freudent...@googlemail.com wrote: > Unfortunately I'm using this approach to bundle my themes with an extension > that extends capability to them. I'm wondering why to remove this feature at > this point of development, since for Firefox 57 upwards XUL based addons will > not work anymore. > There should be a blog post coming up soon in the Add-ons Blog [1] explaining our plans for themes. I suggest you also give the latest post a look [2]. Jorge [1] https://blog.mozilla.org/addons/ [2] https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Embeddable Browser
Hello guys, I do not know if this serious or the right group to do this ask, but I will try here rss Xulrunner no longer has updates, where do I find information or documentation from a substitute for it? I am currently researching information about Gecko and Firefox to set up an embeddable browser to replace what I did with Xulrunner, but I find little information, can anyone give me a light on this? Thank you: D ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
