[Firefox Desktop] Issues found: October 12th to October 16th

Hi everyone, Here's the list of new issues found and filed by the Desktop Manual QA team last week (Week 42: October 12 - October 16). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: Intent to implement and ship: HTMLElement.innerText

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2015 06:02 AM, Robert O'Callahan wrote: > https://bugzilla.mozilla.org/show_bug.cgi?id=264412 > > Webkit, Blink and Trident have been shipping this for years without > a spec and with poor interop. We held off on implementing it since > you

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote: >> >> Eventually |mach build| should just do the right >> thing, no matter what files you've touched... > > The problem is that definitions of "right thing" differ depending on the > goal, right? I'm using the standard build

Re: Decommissioning "dumbmake"

On 2015-10-19 1:17 AM, Bobby Holley wrote: I've heard two compelling arguments against the current setup: (1) It's inconsistent. (2) It causes unnecessary overhead when you do |mach build foo bar| because we link between foo and bar. I don't recall reading (2) in this thread, and it certainly

Re: Decommissioning "dumbmake"

On 10/18/2015 10:17 PM, Bobby Holley wrote: On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote: On 10/18/15 7:14 PM, Nicholas Nethercote wrote: Eventually |mach build| should just do the right thing, no matter what files you've touched... The problem is that

Re: Intent to unship: jar: URIs from content

On Sat, Oct 17, 2015 at 3:48 PM, Ben Kelly wrote: > On Oct 16, 2015 6:17 PM, "Robert O'Callahan" wrote: > > I guess the right fix would be to have a Web proxy service that accepts > > URLs in a custom format, unpacks ZIP files and serves their contents.

Re: Intent to implement and ship: HTMLElement.innerText

On Tue, Oct 20, 2015 at 1:18 AM, Ms2ger wrote: > Please submit tests to web-platform-tests and create a pull request to > the HTML standard. > Will do, after a decent interval to collect feedback. I wrote web-platform-tests to land with our implementation. Rob -- lbir ye,ea

Re: Decommissioning "dumbmake"

> > Also, .h dependency proliferation is a real problem for build system > performance, especially with the autogenerated mozilla-include.h (which > contains things from every AC_DEFINE in configure.in - an add AC_DEFINE, > invalidate everything). If you build the tips of mozilla-central from 24h

Re: Decommissioning "dumbmake"

On Mon, Oct 19, 2015 at 11:47 AM, Bobby Holley wrote: > On Mon, Oct 19, 2015 at 8:20 AM, Josh Matthews > wrote: > > > On 2015-10-19 1:17 AM, Bobby Holley wrote: > > > >> I've heard two compelling arguments against the current setup: > >> (1) It's

Re: Decommissioning "dumbmake"

On Mon, Oct 19, 2015 at 8:20 AM, Josh Matthews wrote: > On 2015-10-19 1:17 AM, Bobby Holley wrote: > >> I've heard two compelling arguments against the current setup: >> (1) It's inconsistent. >> (2) It causes unnecessary overhead when you do |mach build foo bar| >>

Re: Decommissioning "dumbmake"

On 16/10/2015 08:15, Mike Hommey wrote: > There are however now two build targets that can do the right thing for > most use cases: > - mach build binaries, which will build C/C++ related things > appropriately > - mach build faster, which will build JS, XUL, CSS, etc. (iow, non > C/C++)

Removing "nsDebug" logger

I am removing the "nsDebug" logger [1] in bug 1215629 [2]. It was added some 12 years ago and the purpose has seemingly been lost over the years. If you happen to rely on this being available please let us know. If I don't hear any strong objections in the next day I will land the removal

Re: Intent to unship: jar: URIs from content

On 10/19/15 4:07 PM, Gregory Szorc wrote: Or you could register a custom content type handler (possibly via a special "Gecko Hackers" Firefox add-on) that runs an appropriate mach command when said file is downloaded. This ignores the point about running the file after downloading having

Re: Intent to implement and ship: window.orientation and orientationchange event

As someone pushing for the ScreenOrientation API, I agree with this intent nonetheless. It *might* be worth warning about this property being inconsistent, and that it's better for users to use the ScreenOrientation API. But I think it's really only worth doing if this is something that other

Re: Intent to implement and ship: webkitMatchesSelector

On 10/19/15 12:46 PM, Anne van Kesteren wrote: On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky wrote: Summary: The web more or less depends on one of the prefixed versions of matchesSelector (being implemented). I think you mean matches() is being implemented, while the web

Intent to implement and ship: window.orientation and orientationchange event

*Summary*: window.orientation returns a value corresponding to the screen orientation. The orientationchange event is fired when the orientation of the viewport is changed. These features are non-standard but have been implemented by other browser vendors on mobile platforms leading to widespread

Intent to implement and ship: webkitMatchesSelector

Summary: The web more or less depends on one of the prefixed versions of matchesSelector (being implemented). We might as well implement the webkit one and drop the moz one. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1216193 Standard:

Re: Intent to implement and ship: webkitMatchesSelector

On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky wrote: > Summary: The web more or less depends on one of the prefixed versions of > matchesSelector (being implemented). I think you mean matches() is being implemented, while the web depends on a prefixed version of