Re: Intent to implement and ship: DOMTokenList.prototype.supports

On 5/4/16 12:06 AM, Matthew N. wrote: A green plus sign appears above the magnifying glass in the search bar for rel="search" and the menu allows you to add that engine to the browser. You can test in a new profile with https://bugzilla.mozilla.org/ Ah, so it does! OK, I'll add "search" to

Re: Intent to implement and ship: DOMTokenList.prototype.supports

On 2016-05-03 9:01 PM, Boris Zbarsky wrote: Looking at this code, there's also similar handling for "search", right? Again, not sure whether that's exposed in the default UI. A green plus sign appears above the magnifying glass in the search bar for rel="search" and the menu allows you to

Re: Intent to implement and ship: DOMTokenList.prototype.supports

On 5/3/16 10:53 PM, Karl Dubost wrote: for feed, I guess, it is still in the menu Hmm. Where? and you can put it back on the main bar Ah, indeed. I guess we could try to do something where Gecko would report "feed" as supported if that button is on the toolbar, but that seems

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Tue, May 3, 2016 at 11:11 PM, Xidorn Quan wrote: > On Wed, May 4, 2016 at 9:46 AM, Lawrence Mandel > wrote: > >> On Tue, May 3, 2016 at 6:56 PM, Mike Hommey wrote: >> >> > On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Wed, May 4, 2016 at 9:46 AM, Lawrence Mandel wrote: > On Tue, May 3, 2016 at 6:56 PM, Mike Hommey wrote: > > > On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach wrote: > > > On 5/3/16 4:59 PM, Justin Dolske wrote: > > > > On 5/3/16 12:21 PM, Gregory

Re: Intent to implement and ship: DOMTokenList.prototype.supports

Le 4 mai 2016 à 05:24, Boris Zbarsky a écrit : > In practice, this is the set of values I'm claiming we support: > "import" (if IsImportEnabled()), "prefetch", "dns-prefetch", "stylesheet", > "next", "alternate", "preconnect", "icon". Anything else I'm missing? Do we > do

Re: Intent to implement and ship: DOMTokenList.prototype.supports

On 5/3/16 7:20 PM, Domenic Denicola wrote: Does Firefox support "next" in some interesting way? Yes. We treat it as an alias for "prefetch". I, uh, have no idea why we included "next" but not "prev". The theory, presumably, is that people typically go forward through things in order.

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Tue, May 3, 2016 at 6:56 PM, Mike Hommey wrote: > On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach wrote: > > On 5/3/16 4:59 PM, Justin Dolske wrote: > > > On 5/3/16 12:21 PM, Gregory Szorc wrote: > > > > > > > * The update server has been reconfigured to not serve

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Tue, May 3, 2016 at 3:53 PM, Chris Peterson wrote: > On 5/3/16 3:11 AM, Xidorn Quan wrote: > >> > Then we should plan to drop Universal builds in the same release, >>> > because without supporting 10.6 or 32-bit NPAPI plugins, the 32-bit >>> half >>> > of the build is

Re: Intent to implement and ship: DOMTokenList.prototype.supports

On Tuesday, May 3, 2016 at 4:24:26 PM UTC-4, Boris Zbarsky wrote: > In practice, this is the set of values I'm claiming we > support: "import" (if IsImportEnabled()), "prefetch", "dns-prefetch", > "stylesheet", "next", "alternate", "preconnect", "icon". Anything else > I'm missing? Do we do

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach wrote: > On 5/3/16 4:59 PM, Justin Dolske wrote: > > On 5/3/16 12:21 PM, Gregory Szorc wrote: > > > > > * The update server has been reconfigured to not serve Nightly > > > updates to > > > 10.6-10.8 (bug 1269811) > > > > Are we going to be

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 5/3/16 3:11 AM, Xidorn Quan wrote: > Then we should plan to drop Universal builds in the same release, > because without supporting 10.6 or 32-bit NPAPI plugins, the 32-bit half > of the build is just cruft. That doesn't mean we can't remove 32-bit NPAPI support on OS X sooner than 53.

Re: Intent to deprecate: MacOS 10.6-10.8 support

It can be done with a one-off update mar file that includes the files that aren't included in an update. On Tue, May 3, 2016 at 3:18 PM, Adam Roach wrote: > On 5/3/16 4:59 PM, Justin Dolske wrote: > >> On 5/3/16 12:21 PM, Gregory Szorc wrote: >> >> * The update server has been

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 5/3/16 4:59 PM, Justin Dolske wrote: On 5/3/16 12:21 PM, Gregory Szorc wrote: * The update server has been reconfigured to not serve Nightly updates to 10.6-10.8 (bug 1269811) Are we going to be showing some kind of notice to affected users upon Release? That is, if I'm a 10.6 user and

Re: Intent to deprecate: MacOS 10.6-10.8 support

App update has the ability to show the user a message that the system is no longer supported based on the update.xml served by release engineering. Robert On Tue, May 3, 2016 at 2:59 PM, Justin Dolske wrote: > On 5/3/16 12:21 PM, Gregory Szorc wrote: > > * The update server

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 5/3/16 12:21 PM, Gregory Szorc wrote: * The update server has been reconfigured to not serve Nightly updates to 10.6-10.8 (bug 1269811) Are we going to be showing some kind of notice to affected users upon Release? That is, if I'm a 10.6 user and I update to Firefox 48, at some point

Re: Intent to implement and ship: DOMTokenList.prototype.supports

On 5/3/16 4:38 PM, smaug wrote: Do we need "import" ever? Is IsImportEnabled() ever true? I guess that will be removed once we remove import related code. Seems plausible. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement and ship: DOMTokenList.prototype.supports

Ok to me, given that adding the API to the platform is supported by other browser vendors too. (Though it is a bit mystery to me why DOMTokenList.supports is considered fine when it is pretty much similar feature to Node.isSupported and that one was considered harmful to the platform. But

Intent to implement and ship: DOMTokenList.prototype.supports

Summary: A way to feature-detect which values of various tokenlist attributes actually do something. Useful for things like which iframe sandbox tokens are supported, or what "rel" values for are supported. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1257849 Link to Standard: If only

Re: Intent to implement and ship: rel="noopener" on links

On 4/25/16 10:47 PM, Boris Zbarsky wrote: Ah. Perhaps we should hold off on doing this until https://bugzilla.mozilla.org/show_bug.cgi?id=1257849 is fixed then. And the window.open thing would still not be detectable, so people would probably start assuming the anchor bit implied the window

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Mon, May 2, 2016 at 4:10 PM, Gregory Szorc wrote: > On Mon, May 2, 2016 at 3:51 PM, Lawrence Mandel > wrote: > >> On Mon, May 2, 2016 at 2:28 PM, Ralph Giles wrote: >> >> > On Fri, Apr 29, 2016 at 9:52 PM, Lawrence Mandel

Re: libc++ enabled for Android / C++11 standard library update

On Tue, May 3, 2016 at 10:57 AM, Nathan Froyd wrote: > As the subject suggests. It is also strongly suggested that you now > use NDK r11b or above for your local Android development; this is what > automation uses and what |mach bootstrap| installs. It's worth pointing out

libc++ enabled for Android / C++11 standard library update

As the subject suggests. It is also strongly suggested that you now use NDK r11b or above for your local Android development; this is what automation uses and what |mach bootstrap| installs. This change leaves Mac as our only tier-1 platform without a C++11 standard library. Given the recent

Re: libc++ enabled for Android / C++11 standard library update

On Tue, May 3, 2016 at 7:57 AM, Nathan Froyd wrote: > As the subject suggests. It is also strongly suggested that you now > use NDK r11b or above for your local Android development; this is what > automation uses and what |mach bootstrap| installs. > > This change leaves Mac

Re: Can MAX_REFLOW_DEPTH be increased?

On 5/3/16 6:59 AM, Aryeh Gregor wrote: Sure. The same is potentially true if the stack depth limit is 200. Did anyone do all these calculations to determine that was safe, or did they just pick a number and see what worked? I don't know, honestly. This code is pretty old. By your logic,

"Firefox 48 for Developers"

Hi! Now that it left Nightly I have updated the developers release notes for Fx 48 with the information that has transmitted to us (mainly via the dev-doc-needed keyword). https://developer.mozilla.org/en-US/Firefox/Releases/48 Feel free to have a look, comment, complain, correct, etc. In

Re: Changes to bugzilla "plugins" product

On Mon, May 2, 2016 at 3:43 PM, Emma Humphries wrote: > Andrew, can you do a pass over the bugs since Jan 1st and, and let's > rename this FFx::Add Ons Compatablity so that it's clear it's not plugins. > ​Extensions and plugins are both types of add-ons​ so renaming makes it

Re: Changes to bugzilla "plugins" product

It's fine to keep it as-is for now, but I think the goal should be to get rid of it (and possibly Tech Evangelism :: Addons too) for the same reasons as Benjamin noted in his first email. Seem like most of this component's original intent (naming aside) is covered by those new components.

Re: Changes to bugzilla "plugins" product

Will Firefox :: Extension Compatibility also be rolled into this new :: Other component? (There are ~700 open bugs there still, most of which look pretty stale.) Justin On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg wrote: > There used to be a bugzilla.mozilla.org

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

On Tue, May 03, 2016 at 03:14:35PM +0300, Henri Sivonen wrote: > (Looks like Zopfli was investigated in bug > https://bugzilla.mozilla.org/show_bug.cgi?id=1173894 .) And bug 1234008, where you'll learn that zopflipng removes PNG chunks that are important to us, including frames in animated PNGs.

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

On Mon, May 2, 2016 at 10:49 PM, Margaret Leibovic wrote: > On Sun, May 1, 2016 at 6:54 AM, Henri Sivonen wrote: >> >> >> What bothers me the most regarding size of what we ship is >> >> * Failure to make the most out of compression (i.e. Zopfli)

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

It's not just strange. It's against Ecma's explicit organization-wide policy. -j On Tue, May 3, 2016 at 1:13 AM, Anne van Kesteren wrote: > On Tue, May 3, 2016 at 2:17 AM, Jeff Walden wrote: > > Using a library to do certain things we do other ways right

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 9:58 PM, Boris Zbarsky wrote: > For a 900KB stack (what we have on Windows, per > ) > 512 DOM nodes deep corresponds to ~2KB per DOM node. 200 deep corresponds > to 5KB.

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Tue, May 3, 2016 at 7:48 PM, Ted Mielczarek wrote: > On Mon, May 2, 2016, at 08:26 PM, Chris Peterson wrote: > > We're tentatively planning to remove NPAPI support (for plugins other > > than Flash) in 53 because 52 is the next ESR. We'd like ESR 52 to > > support NPAPI

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Mon, May 2, 2016, at 08:26 PM, Chris Peterson wrote: > We're tentatively planning to remove NPAPI support (for plugins other > than Flash) in 53 because 52 is the next ESR. We'd like ESR 52 to > support NPAPI as a transition option for enterprise users that rely on > Java. Then we should

[Firefox Desktop] Issues found: April 25th to 29th

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA team last week, *April 25th - April 29th* (week 17). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

On Tue, May 3, 2016 at 2:17 AM, Jeff Walden wrote: > Using a library to do certain things we do other ways right now, in sometimes > inferior fashion, doesn't seem inherently objectionable to me. So long as the > library's internal decisions don't bleed too far into the