Re: Searchfox (new code search tool)

[Mike Hommey]

On Mon, Jun 06, 2016 at 09:35:34PM -0700, Bill McCloskey wrote:
> Hi everyone,
> 
> I would like to announce a new tool I've been working on for source
> code searching called Searchfox (http://searchfox.org). If you use MXR
> or DXR, I recommend you try Searchfox. Here are some of the benefits:

I'm going to sound negative, but why? Or more precisely, why not
contribute to DXR to add those features that you implemented in
searchfox that DXR doesn't have?

MXR is already taking too long to fade out of existence, do we really
want yet another different tool?

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [desktop] Heads up: Tons of IPCError-browser | ShutDownKill reports incoming

[Nicholas Nethercote]

BTW, you can tell if a crash report was triggered by this new feature
by looking for the presence of the "submitted from infobar" field.

On Sat, Jun 4, 2016 at 2:37 AM, Ehsan Akhgari  wrote:
> FYI
>
> -- Forwarded message --
> From: Lawrence Mandel 
> Date: Thu, Jun 2, 2016 at 6:10 PM
> Subject: [desktop] Heads up: Tons of IPCError-browser | ShutDownKill
> reports incoming
> To: release-drivers 
>
>
> -- Forwarded message --
>
> From: Andrew McCreight 
> Date: Thu, Jun 2, 2016 at 5:49 PM
> Subject: Heads up: Tons of IPCError-browser | ShutDownKill reports incoming
> To: "projectuptime-." 
>
>
> Bug 1269998 landed early today or yesterday, and prompts users to submit
> all old unsubmitted crash reports. One consequence of this is that crashes
> that happen because shutdown takes too long are now going to be submitted.
> Before, because they were happening during shutdown, there was no crash
> report UI shown to the users, so they were not being submitted.
>
> This is a huge % of all crashes. For instance, for the 6/1 hour 3 builds,
> they are currently showing up as 30% of all crashes. It also isn't clear
> they are really crashes we should care about, as they are really more of a
> sign of slow shutdown.
>
> I think this is going to affect all builds on all channels, so brace
> yourselves.
>
> Andrew
>
> ___
> release-drivers mailing list
> release-driv...@mozilla.org
> https://mail.mozilla.org/listinfo/release-drivers
> ___
> 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: Intent to remove: Error Console

[Emma Humphries]

That works for me. If you'd make the ticket to remove the component from
bmo dependent on the ticket to remove the code from moz-central and cc me
on the latter as we discussed, that'd be awesome. Thanks.

On Mon, Jun 6, 2016 at 1:48 PM, Brian Grinstead 
wrote:

>
> > On Jun 6, 2016, at 1:20 PM, Emma Humphries  wrote:
> >
> > There's 77 open bugs in the component, http://mzl.la/1YbBKto, how would
> you like to handle those?
>
> The majority of these look like frontend-related bugs and feature requests
> which could be closed once the code is removed.  I suggest a mass-closure
> with a comment to re-categorize it into Developer Tools: Console if they
> are also applicable to the Browser Console.
>
> > -- Emma
> >
> > On Mon, Jun 6, 2016 at 1:04 PM, Brian Grinstead 
> wrote:
> > There is an Error Console feature in toolkit that's been replaced by the
> Browser Console.  We'd like to remove associated code in
> toolkit/components/console/ and the component in bugzilla (Toolkit: Error
> Console).  This will also remove the —jsconsole command line flag for
> consumers that don’t use devtools.
> >
> > The code isn't used at all in Firefox, as discussed in
> https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/XYPqQ58ndX4/discussion.
> It’s also now possible to migrate usages to the Browser Console i.e.
> Seamonkey is no longer using it as of bug 1223341.
> >
> > Brian
> > ___
> > 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: Intent to remove: Error Console

[Brian Grinstead]

> On Jun 6, 2016, at 1:20 PM, Emma Humphries  wrote:
> 
> There's 77 open bugs in the component, http://mzl.la/1YbBKto, how would you 
> like to handle those? 

The majority of these look like frontend-related bugs and feature requests 
which could be closed once the code is removed.  I suggest a mass-closure with 
a comment to re-categorize it into Developer Tools: Console if they are also 
applicable to the Browser Console.

> -- Emma
> 
> On Mon, Jun 6, 2016 at 1:04 PM, Brian Grinstead  
> wrote:
> There is an Error Console feature in toolkit that's been replaced by the 
> Browser Console.  We'd like to remove associated code in 
> toolkit/components/console/ and the component in bugzilla (Toolkit: Error 
> Console).  This will also remove the —jsconsole command line flag for 
> consumers that don’t use devtools.
> 
> The code isn't used at all in Firefox, as discussed in 
> https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/XYPqQ58ndX4/discussion.
>   It’s also now possible to migrate usages to the Browser Console i.e. 
> Seamonkey is no longer using it as of bug 1223341.
> 
> Brian
> ___
> 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

OS X Nightly Content Sandbox Changes

[Haik Aftandilian]

The fix for bug 1272772 [1] makes some minor changes to the OS X content
sandbox which is only enabled on Nightly. More changes will come as we
whittle down and simplify the sandbox rules. If you think you are hitting a
regression due to sandboxing on OS X, it's a good idea to check the OS X
Console application where you can filter on "plugin-container" or "sandbox"
and look for deny log entries.

You can also experiment with disabling the content sandbox on OS X Nightly
by setting the preference security.sandbox.content.level=0.

File bugs with product=Core and component=Security: Process Sandboxing.

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1272772

Thanks,
Haik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Boris Zbarsky]

On 6/3/16 11:41 AM, Boris Zbarsky wrote:

* Chrome: has been shipping the behavior I'm proposing to change to
since Chrome 50, I believe.  Current Chrome release version is 51.


One note: earlier versions of Chrome claimed [object Object] for DOM 
prototypes.  So the claim the Google folks are making is that returning 
[object FooPrototype] is not needed for web compat.



Possible alternatives: We could make @@toStringTag an accessor on the
prototype that returns different things for instances and the prototype
itself.


The hard part here is convincing the Chrome folks.

-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: Error Console

[Emma Humphries]

There's 77 open bugs in the component, http://mzl.la/1YbBKto, how would you
like to handle those?

-- Emma

On Mon, Jun 6, 2016 at 1:04 PM, Brian Grinstead 
wrote:

> There is an Error Console feature in toolkit that's been replaced by the
> Browser Console.  We'd like to remove associated code in
> toolkit/components/console/ and the component in bugzilla (Toolkit: Error
> Console).  This will also remove the —jsconsole command line flag for
> consumers that don’t use devtools.
>
> The code isn't used at all in Firefox, as discussed in
> https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/XYPqQ58ndX4/discussion.
> It’s also now possible to migrate usages to the Browser Console i.e.
> Seamonkey is no longer using it as of bug 1223341.
>
> Brian
> ___
> 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: Changes under /storage

[Jan Varga]

On 06/06/16 21:57, smaug wrote:

On 06/06/2016 09:24 PM, Jan Varga wrote:

On 06/06/16 17:30, smaug wrote:


On 06/06/2016 02:25 PM, Jan Varga wrote:
I landed a fix for bug 1195930 ( Use origin in QuotaManager) today, 
it's now on m-c.


We had to do backwards-incompatible changes under /storage 
directory, so once a profile is used with newest nigthly, then any 
storage API
controlled by Quota Manager (IndexedDB, DOM cache, asmjs cache) 
won't work in older builds.


We didn't have a versioning schema for /storage before 
this bug, so the incompatibility is signaled by this nonsensical 
warning in older

builds:

WARNING: Unknown file found!: file 
/Users/joe/Sources/Mozilla/dom/quota/ActorsParent.cpp, line 3541


Jan




I assume there are plans to warn users about this kind of issue. 
Just printing something to the terminal isn't really useful.

yeah, bug 1246615

Could we clean up the data if the FF version user is using can't 
handle it?

hm, clean up indexedDB databases, etc. ?

yes, wipe out data so that user gets a browser which works. Perhaps 
warn/ask user before doing it?

ok, but let's discuss about it in the bug 1246615

Jan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: Error Console

[Brian Grinstead]

There is an Error Console feature in toolkit that's been replaced by the 
Browser Console.  We'd like to remove associated code in 
toolkit/components/console/ and the component in bugzilla (Toolkit: Error 
Console).  This will also remove the —jsconsole command line flag for consumers 
that don’t use devtools.

The code isn't used at all in Firefox, as discussed in 
https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/XYPqQ58ndX4/discussion.
  It’s also now possible to migrate usages to the Browser Console i.e. 
Seamonkey is no longer using it as of bug 1223341.

Brian
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes under /storage

[smaug]

On 06/06/2016 09:24 PM, Jan Varga wrote:

On 06/06/16 17:30, smaug wrote:


On 06/06/2016 02:25 PM, Jan Varga wrote:

I landed a fix for bug 1195930 ( Use origin in QuotaManager) today, it's now on 
m-c.

We had to do backwards-incompatible changes under /storage directory, 
so once a profile is used with newest nigthly, then any storage API
controlled by Quota Manager (IndexedDB, DOM cache, asmjs cache) won't work in 
older builds.

We didn't have a versioning schema for /storage before this bug, so 
the incompatibility is signaled by this nonsensical warning in older
builds:

WARNING: Unknown file found!: file 
/Users/joe/Sources/Mozilla/dom/quota/ActorsParent.cpp, line 3541

Jan




I assume there are plans to warn users about this kind of issue. Just printing 
something to the terminal isn't really useful.

yeah, bug 1246615


Could we clean up the data if the FF version user is using can't handle it?

hm, clean up indexedDB databases, etc. ?


yes, wipe out data so that user gets a browser which works. Perhaps warn/ask 
user before doing it?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Nick Fitzgerald]

Ok, I've filed this bug to use @@toStringTag in the debugger instead of
Debugger.Object.prototype.class:
https://bugzilla.mozilla.org/show_bug.cgi?id=1278310

On Mon, Jun 6, 2016 at 10:35 AM, Boris Zbarsky  wrote:

> On 6/6/16 12:23 PM, Nick Fitzgerald wrote:
>
>> Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
>> misunderstood the scope of this proposal, the class name exposed by that
>> getter should not change, only the `Object.prototype.toString.call(thing)`
>> would change.
>>
>
> You misunderstood the scope.  We would be changing the class string if we
> change the web-facing behavior here.
>
> Or put another way, if we want to change to @@toStringTag for DOM objects
> (which we do) and _if_ we want that change to change the behavior of
> Object.prototype.toString on DOM prototypes, then we would roll that out in
> two stages:
>
> 1)  Change the class strings on DOM prototype objects, so the
> Object.prototype.toString changes (and the Debugger.Object.prototype.class
> thing changes too, sadly).
>
> 2)  Add @@toStringTag stuff.
>
> The idea being to separate breakage from the Object.prototype.toString
> changing from breakage from using @@toStringTag instead of class strings to
> implement the behavior.
>
>
> -Boris
> ___
> 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: Generating Visual Studio project files by default

[Gregory Szorc]

On Thu, Jun 2, 2016 at 9:47 PM, Jean-Yves Avenard 
wrote:

> On Wednesday, May 25, 2016 at 9:00:48 AM UTC+10, Gregory Szorc wrote:
> > This change was tracked in bug 1275297. Bug 1275419 tracks a follow-up to
> > allow disabling their generation.
>
> so when is xcode support coming too ? :)
>
>
Patches welcome.

I've heard bad stories about Xcode scalability to large projects. It might
be prudent to Eclipse or another IDE on OS X.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes under /storage

[Jan Varga]

On 06/06/16 17:30, smaug wrote:


On 06/06/2016 02:25 PM, Jan Varga wrote:
I landed a fix for bug 1195930 ( Use origin in QuotaManager) today, 
it's now on m-c.


We had to do backwards-incompatible changes under /storage 
directory, so once a profile is used with newest nigthly, then any 
storage API
controlled by Quota Manager (IndexedDB, DOM cache, asmjs cache) won't 
work in older builds.


We didn't have a versioning schema for /storage before this 
bug, so the incompatibility is signaled by this nonsensical warning 
in older builds:


WARNING: Unknown file found!: file 
/Users/joe/Sources/Mozilla/dom/quota/ActorsParent.cpp, line 3541


Jan




I assume there are plans to warn users about this kind of issue. Just 
printing something to the terminal isn't really useful.

yeah, bug 1246615

Could we clean up the data if the FF version user is using can't 
handle it?

hm, clean up indexedDB databases, etc. ?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 32-bit developer edition?

[Ben Kelly]

On Mon, Jun 6, 2016 at 1:47 PM, Jared Wein  wrote:

> We shouldn't hold back on providing a link to 64-bit Dev Edition users en
> masse. I worry that running an A/B test will slow down the full release
> without telling us much of anything that we don't already know.
>
> The user agent string says if the system is 64-bit, so sniffing is already
> possible.
>
> Ben, can you file the bug in Mozilla.org::webdev to get the link added to
> the download page?
>

Sure:

https://bugzilla.mozilla.org/show_bug.cgi?id=1278315
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 32-bit developer edition?

[Jared Wein]

On Fri, Jun 3, 2016 at 11:02 AM, Javaun Moradi  wrote:

> +Clarkbw, who runs Dev Edition.
>
> Expansion of 64 bit was on hold pending the release of 47, where we had
> some critical sandboxing issues fixed and (conveniently) the Widevine CDM
> also hit that timeframe for video support.
>
> It’s an interesting idea to hit developers, who are a bit savvier. We
> assume elimination of small OOM and JS performance gains, security overall
> will be a tradeoff.
>



> We need more users in-field before we start rolling win64 out by default
> to normal people. DevEdition is a potentially compelling hook. We were
> going to offer 64 selectively on the download page to some users in an A/B
> test to try to get numbers up. Ideally, we’d be able to sniff who could run
> it, since we don’t have a stub installer.
>

We shouldn't hold back on providing a link to 64-bit Dev Edition users en
masse. I worry that running an A/B test will slow down the full release
without telling us much of anything that we don't already know.

The user agent string says if the system is 64-bit, so sniffing is already
possible.

Ben, can you file the bug in Mozilla.org::webdev to get the link added to
the download page?

Thanks,
Jared
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Boris Zbarsky]

On 6/6/16 12:23 PM, Nick Fitzgerald wrote:

Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
misunderstood the scope of this proposal, the class name exposed by that
getter should not change, only the `Object.prototype.toString.call(thing)`
would change.


You misunderstood the scope.  We would be changing the class string if 
we change the web-facing behavior here.


Or put another way, if we want to change to @@toStringTag for DOM 
objects (which we do) and _if_ we want that change to change the 
behavior of Object.prototype.toString on DOM prototypes, then we would 
roll that out in two stages:


1)  Change the class strings on DOM prototype objects, so the 
Object.prototype.toString changes (and the 
Debugger.Object.prototype.class thing changes too, sadly).


2)  Add @@toStringTag stuff.

The idea being to separate breakage from the Object.prototype.toString 
changing from breakage from using @@toStringTag instead of class strings 
to implement the behavior.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Jim Blandy]

Well, the Debugger.Object.prototype.class getter shouldn't change, but
perhaps devtools shouldn't use it any more. Devtools should be displaying
objects in a way that doesn't surprise developers.

It seems to me the ideal behavior would be for Devtools to show objects in
the way that the ES6 standard toString methods would display them, and then
if those have been modified, attempt to display them as the modifications
suggest, to the extent that that can be done safely.

On Mon, Jun 6, 2016 at 9:23 AM, Nick Fitzgerald 
wrote:

> Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
> misunderstood the scope of this proposal, the class name exposed by that
> getter should not change, only the `Object.prototype.toString.call(thing)`
> would change.
>
> On Mon, Jun 6, 2016 at 12:18 AM, Panos Astithas  wrote:
>
> > On Fri, Jun 3, 2016 at 8:21 PM, Nick Fitzgerald  >
> > wrote:
> >
> >> On Fri, Jun 3, 2016 at 8:41 AM, Boris Zbarsky  wrote:
> >>
> >> > Devtools bug: none so far, but maybe we need one?  Does devtools rely
> on
> >> > the JSClass name or Object.prototype.toString anywhere?
> >> >
> >>
> >> ​I think we are fine. There are certainly places where we use the
> >> `Object.prototype.toString.call(thing) === "[object Whatever]"`​ hack,
> but
> >> I don't see any instances that would be tripped up by these changes.
> >>
> >>
> >>
> https://dxr.mozilla.org/mozilla-central/search?q=path%3Adevtools+%22toString.call(%22=false
> >>
> >
> > Don't we still use the JSClass name in the variables view to indicate the
> > object type (reflected from Debugger.Object.prototype.class)?
> >
> > Panos
> >
> >
> ___
> 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: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Nick Fitzgerald]

Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
misunderstood the scope of this proposal, the class name exposed by that
getter should not change, only the `Object.prototype.toString.call(thing)`
would change.

On Mon, Jun 6, 2016 at 12:18 AM, Panos Astithas  wrote:

> On Fri, Jun 3, 2016 at 8:21 PM, Nick Fitzgerald 
> wrote:
>
>> On Fri, Jun 3, 2016 at 8:41 AM, Boris Zbarsky  wrote:
>>
>> > Devtools bug: none so far, but maybe we need one?  Does devtools rely on
>> > the JSClass name or Object.prototype.toString anywhere?
>> >
>>
>> ​I think we are fine. There are certainly places where we use the
>> `Object.prototype.toString.call(thing) === "[object Whatever]"`​ hack, but
>> I don't see any instances that would be tripped up by these changes.
>>
>>
>> https://dxr.mozilla.org/mozilla-central/search?q=path%3Adevtools+%22toString.call(%22=false
>>
>
> Don't we still use the JSClass name in the variables view to indicate the
> object type (reflected from Debugger.Object.prototype.class)?
>
> Panos
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes under /storage

[smaug]

On 06/06/2016 02:25 PM, Jan Varga wrote:

I landed a fix for bug 1195930 ( Use origin in QuotaManager) today, it's now on 
m-c.

We had to do backwards-incompatible changes under /storage directory, 
so once a profile is used with newest nigthly, then any storage API
controlled by Quota Manager (IndexedDB, DOM cache, asmjs cache) won't work in 
older builds.

We didn't have a versioning schema for /storage before this bug, so 
the incompatibility is signaled by this nonsensical warning in older builds:

WARNING: Unknown file found!: file 
/Users/joe/Sources/Mozilla/dom/quota/ActorsParent.cpp, line 3541

Jan




I assume there are plans to warn users about this kind of issue. Just printing 
something to the terminal isn't really useful.
Could we clean up the data if the FF version user is using can't handle it?


-Olli
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Performance Working Group

[Jack Moffitt]

Many of the proposed output specifications for this seem quite useful
for the kinds of work we are doing in Servo. While this is aimed at
web developers, it seems very useful for browser vendors to be
measuring things the same way. Having standard ways of doing this
means we'll be able to get more accurate cross browser comparisons.

This seems like something we should support.

jack.

On Fri, Jun 3, 2016 at 5:57 PM, L. David Baron  wrote:
> The W3C is proposing a revised charter for:
>
>   Web Performance Working Group
>   https://w3c.github.io/charter-webperf/
>   https://lists.w3.org/Archives/Public/public-new-work/2016Jun/0001.html
>
> Mozilla has the opportunity to send comments or objections through
> Thursday, June 30.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> 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

Fwd: [desktop] Heads up: Tons of IPCError-browser | ShutDownKill reports incoming

[Ehsan Akhgari]

FYI

-- Forwarded message --
From: Lawrence Mandel 
Date: Thu, Jun 2, 2016 at 6:10 PM
Subject: [desktop] Heads up: Tons of IPCError-browser | ShutDownKill
reports incoming
To: release-drivers 


-- Forwarded message --

From: Andrew McCreight 
Date: Thu, Jun 2, 2016 at 5:49 PM
Subject: Heads up: Tons of IPCError-browser | ShutDownKill reports incoming
To: "projectuptime-." 


Bug 1269998 landed early today or yesterday, and prompts users to submit
all old unsubmitted crash reports. One consequence of this is that crashes
that happen because shutdown takes too long are now going to be submitted.
Before, because they were happening during shutdown, there was no crash
report UI shown to the users, so they were not being submitted.

This is a huge % of all crashes. For instance, for the 6/1 hour 3 builds,
they are currently showing up as 30% of all crashes. It also isn't clear
they are really crashes we should care about, as they are really more of a
sign of slow shutdown.

I think this is going to affect all builds on all channels, so brace
yourselves.

Andrew

___
release-drivers mailing list
release-driv...@mozilla.org
https://mail.mozilla.org/listinfo/release-drivers
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Changes under /storage

[Jan Varga]

I landed a fix for bug 1195930 ( Use origin in QuotaManager) today, it's 
now on m-c.


We had to do backwards-incompatible changes under /storage 
directory, so once a profile is used with newest nigthly, then any 
storage API controlled by Quota Manager (IndexedDB, DOM cache, asmjs 
cache) won't work in older builds.


We didn't have a versioning schema for /storage before this 
bug, so the incompatibility is signaled by this nonsensical warning in 
older builds:


WARNING: Unknown file found!: file 
/Users/joe/Sources/Mozilla/dom/quota/ActorsParent.cpp, line 3541


Jan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: May 30th to June 3rd

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *May 30 - June 03* (week 22).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1277819 
	Crash in OOM | unknown | js::AutoEnterOOMUnsafeRegion::crash | 
JSCompartment::wrap

Core
JavaScript Engine
TBD NOBODY



*BETA CHANNEL*
none

*AURORA CHANNEL*
none

*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1276650 
	Crash in shutdownhang | __psynch_cvwait | PR_WaitCondVar | omitted> | nsThread::ProcessNextEvent | NS_ProcessNextEvent | 
mozilla::layers::CompositorThreadHolder::Shutdown

Firefox
Developer Tools: Debugger
YES NOBODY
1276607 
The pointer from the text box is missing after disabling RDM
Firefox
Developer Tools: Responsive Design Mode
YES NOBODY
1276629 
Dropdown buttons are not displayed if RDM is enabled
Firefox Developer Tools: Responsive Design Mode YES 
NOBODY
1276644 
The dropdowns are not working if RDM is enabled
Firefox
Developer Tools: Responsive Design Mode
YES NOBODY
1276675 
At mouse over, the 'X' button via Notification bar is offset by ~1px
Firefox
Developer Tools: Shared Components
YES NOBODY
1276661 
[Ubuntu] Notification Bar is intelligible
Firefox
Developer Tools: Framework
YES Jan Honza Odvarko
1276923 
White artifacts and flickering when scrolling on Vimeo videos
Core
Panning and Zooming
YES Jeff Muizelaar
1277271 
security sensitive bug
---
---
YES ---


*ESR CHANNEL*
none

Regards,
Andrei
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Panos Astithas]

On Fri, Jun 3, 2016 at 8:21 PM, Nick Fitzgerald 
wrote:

> On Fri, Jun 3, 2016 at 8:41 AM, Boris Zbarsky  wrote:
>
> > Devtools bug: none so far, but maybe we need one?  Does devtools rely on
> > the JSClass name or Object.prototype.toString anywhere?
> >
>
> ​I think we are fine. There are certainly places where we use the
> `Object.prototype.toString.call(thing) === "[object Whatever]"`​ hack, but
> I don't see any instances that would be tripped up by these changes.
>
>
> https://dxr.mozilla.org/mozilla-central/search?q=path%3Adevtools+%22toString.call(%22=false
>

Don't we still use the JSClass name in the variables view to indicate the
object type (reflected from Debugger.Object.prototype.class)?

Panos
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform