Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Kris Maglione]

On Mon, Sep 24, 2018 at 04:05:22PM -0400, Randell Jesup wrote:

On 9/20/18 5:59 PM, Andrew McCreight wrote:

On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione  wrote:


On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:

So, I don't think we need to do anything fancy with forking - we'd just
need to capture stacks and send them via telemetry rather than as a crash
report. This was the idea behind bug 1209131, which got pretty far along
but never made it to the finish line.


This would actually potentially even give us better information
than fork-and-crash, since we should be able to include JS
stacks in that setup too. We've never been able to do that in
ordinary crash reports, since breakpad doesn't know how to
unwind JS stacks, and we can't safely ask the JS runtime to do
it while we're crashing.



Though keep in mind that any stack that includes content JS is going to
likely count as PII, so it would have to be hidden by default on Soccorro.



Please note that it would be illegal to collect such data
without asking for explicit user consent first.
The GDPR requires a "positive opt-in" mechanism:
https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/consent/
Our current Telemetry permission is an opt-out mechanism.


Right - this would need to be handled in a similar way to real crashes -
pop a crashreporter dialog to let the user submit it.  We just wouldn't
kill the browser (and probably disable future semi-assertions until
restart once we hit and report one to avoid bugging the user too much).


For telemetry assertion reporting, I think BHR is a closer 
analog. That already collects JS stacks.

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

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Randell Jesup]

>On 9/20/18 5:59 PM, Andrew McCreight wrote:
>> On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione  wrote:
>>
>>> On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:
 So, I don't think we need to do anything fancy with forking - we'd just
 need to capture stacks and send them via telemetry rather than as a crash
 report. This was the idea behind bug 1209131, which got pretty far along
 but never made it to the finish line.
>>>
>>> This would actually potentially even give us better information
>>> than fork-and-crash, since we should be able to include JS
>>> stacks in that setup too. We've never been able to do that in
>>> ordinary crash reports, since breakpad doesn't know how to
>>> unwind JS stacks, and we can't safely ask the JS runtime to do
>>> it while we're crashing.
>>>
>>
>> Though keep in mind that any stack that includes content JS is going to
>> likely count as PII, so it would have to be hidden by default on Soccorro.
>
>
>Please note that it would be illegal to collect such data
>without asking for explicit user consent first.
>The GDPR requires a "positive opt-in" mechanism:
>https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/consent/
>Our current Telemetry permission is an opt-out mechanism.

Right - this would need to be handled in a similar way to real crashes -
pop a crashreporter dialog to let the user submit it.  We just wouldn't
kill the browser (and probably disable future semi-assertions until
restart once we hit and report one to avoid bugging the user too much).

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[desktop] Bugs logged by Desktop Release QA in the last 7 days

[Mihai Boldan]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team last two weeks.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/yaludsw5

Bugs logged by Desktop Release QA in the last 7 days:

Firefox: General
NEW - https://bugzil.la/1492818 - After resizing the browser, the page 
is not reloaded and the resulted empty space becomes unusable


Firefox: Installer
NEW - https://bugzil.la/1492369 - [win] Uninstaller survey not scrolling 
to first error on IE


Firefox: Preferences
NEW - https://bugzil.la/1493185 - Content blocking brought in focus on 
the position of Tracking protection after flipping 
browser.contentblocking.ui.enabled on


Core: DOM: Core & HTML
NEW - https://bugzil.la/1492376 - Telegram fails to display content in 
newtab when trying to open embed videos of dailymotion


Core: General
NEW - https://bugzil.la/1491868 - [Linux] Firefox Crashes while updating 
to the latest version


Core: WebRTC: Audio/Video
NEW - https://bugzil.la/1492847 - Permissions for microphone are lost 
after unplugging the headsets while in a call


Toolkit: Add-ons Manager
NEW - https://bugzil.la/1492838 - Firefox breaks after removing/undoing 
a deleted language pack in the same session


DevTools: Inspector
NEW - https://bugzil.la/1493131 - Inspector console is broken after 
loading a website inside a locally saved page


DevTools: Responsive Design Mode
NEW - https://bugzil.la/1492363 - Newtab/AS page empty when enabling RDM 
with a new profile


Web Compatibility Tools: Go Faster
NEW - https://bugzil.la/1492772 - Content scripts are not restored 
properly after the browser is closed or the browser crashes


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/y738vh63


Regards,
Mihai (:mboldan)
Desktop Release QA
--
Mihai Boldan
QC Engineer
Softvision

The content of this communication is classified as Softvision 
Confidential and Proprietary Information.


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

[desktop] Bugs logged by Desktop Release QA in the last 7 days

[Mihai Boldan]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team last two weeks.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/yanv7p74

Bugs logged by Desktop Release QA in the last 7 days:

Firefox: Enterprise Policies
NEW - https://bugzil.la/1491268 - Bookmarks policy's last fields are 
displayed with a different background color


Firefox: Installer
RESOLVED FIXED - https://bugzil.la/1491043 - [win] Styling issues on the 
Uninstaller survey for IE


Firefox: Theme
NEW - https://bugzil.la/1490966 - [Windows 7] Disabled options from 
"Open menu" are blurry


Firefox: Search
NEW - https://bugzil.la/1490614 - Search suggestion dropdown inside 
Overflow menu is not dismissed when open another panel


Core: Audio/Video: Playback
NEW - https://bugzil.la/1491320 - Reddit - embedded youtube videos don't 
hide logo on play


Core: Layout
NEW - https://bugzil.la/1491308 - Playlist content is misplaced on 
Youtube gaming


Core: CSS Parsing and Computation
NEW - ttps://bugzil.la/1491283 - [win][linux] Css issues on zoom out: 
will-change: transform; and -webkit-transform-style: preserve-3d;


Core: Audio/Video: Playback
NEW - https://bugzil.la/1491256 - [win][linux] Youtube registers both 
mute and pause on pressing space key


DevTools: General
NEW - https://bugzil.la/1490358 - The "meatball" and "chevron" menus 
remain open inside a newly opened tab


DevTools: General
NEW - https://bugzil.la/1490327 - [Mac] Artifacts are displayed while 
shrinking the meatball and chevron menus


DevTools: General
NEW - https://bugzil.la/1490285 - The "meatball" menu is misplaced when 
DevTools is zoomed out and displayed on the primary monitor


Cloud Services: Server: Remote Settings
NEW - https://bugzil.la/1490263 - The remotesettings-pi addon is not 
compatible with Fx 63



This is available as a Bugzilla bug list as well: 
https://tinyurl.com/ybjqb63v


Regards,
Mihai (:mboldan)
Desktop Release QA
--
Mihai Boldan
QC Engineer
Softvision

The content of this communication is classified as Softvision 
Confidential and Proprietary Information.


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

Re: User Agent Strings in Firefox and their history

[Eric Shepherd (Sheppy)]

Cool, thanks! If nothing else, please make sure they're not duplicating
material and that they link to each other.

On Thu, Sep 20, 2018 at 12:37 PM Mike Taylor  wrote:

> Hi Eric,
>
> On 9/20/18 11:21 AM, Eric Shepherd (Sheppy) wrote:
> > We actually have a page on MDN about this kind of thing already:
> >
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox.
>
> > If you would like to update or redo that page with your new work, that
> > would be incredibly excellent.
>
> Yeah, thanks for the pointer - I've contributed to that document over
> the years. I'm not sure the level of detail I'm aiming for is
> appropriate for that general purpose page, but there's an opportunity to
> improve the existing MDN page for sure.
>
> thanks,
>
> --
> Mike Taylor
> Web Compat, Mozilla
>
-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: wpt MANIFEST.json has moved out of tree

[James Graham]

On 24/09/2018 14:01, Boris Zbarsky wrote:

On 9/24/18 8:43 AM, James Graham wrote:
Thanks to great work by Outreachy intern Ahilya Sinha (:Cactusmachete) 
[1], the in-tree wpt MANIFEST.json files are no longer used and will 
soon be removed.


That's great news.  :)

Invoking `mach wpt` will now cause a recent wpt manifest to be 
downloaded from Taskcluster into the objdir (if not already present) 
and updated to match the source tree.


Just to make sure I understand, what happens in an offline scenario? 
Does it basically "update" from an empty starting manifest or something 
else?


Yes, that. Nothing is supposed to break if you're entirely offline, but 
a full manifest update is rather slow (technical details: because all 
the metadata is extracted from the test files, and we currently parse 
them using a slow-but-correct Python HTML parser. Switching to html5ever 
or similar is the most obvious path to fix this, but comes with 
additional challenges in terms of workflow and compatibility).

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

Re: PSA: wpt MANIFEST.json has moved out of tree

[Boris Zbarsky]

On 9/24/18 8:43 AM, James Graham wrote:
Thanks to great work by Outreachy intern Ahilya Sinha (:Cactusmachete) 
[1], the in-tree wpt MANIFEST.json files are no longer used and will 
soon be removed.


That's great news.  :)

Invoking `mach wpt` will now cause a recent wpt manifest to be 
downloaded from Taskcluster into the objdir (if not already present) and 
updated to match the source tree.


Just to make sure I understand, what happens in an offline scenario? 
Does it basically "update" from an empty starting manifest or something 
else?


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

PSA: wpt MANIFEST.json has moved out of tree

[James Graham]

Thanks to great work by Outreachy intern Ahilya Sinha (:Cactusmachete) 
[1], the in-tree wpt MANIFEST.json files are no longer used and will 
soon be removed.


Invoking `mach wpt` will now cause a recent wpt manifest to be 
downloaded from Taskcluster into the objdir (if not already present) and 
updated to match the source tree. Running `mach wpt-manifest-update` 
manually should no longer be necessary. Hopefully this fixes the many 
issues caused by having this file under source control.


The tradeoff for auto-updating the manifest is an corresponding delay in 
startup for wpt tests. In order to reduce this as much as possible, 
there is ongoing work to speed up manifest updates [2].


If you notice regressions from this change, please file a bug in the 
Testing::web-platform-tests component and needinfo me.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1473915
[2] https://github.com/web-platform-tests/wpt/pull/12553
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust and --enable-shared-js

[Boris Zbarsky]

On 9/24/18 4:04 AM, Henri Sivonen wrote:

How important is --enable-shared-js? I gather its use case is making
builds faster for SpiderMonkey developers.


My use case for it is to be able to use the "exclude samples from 
library X" or "collapse library X" tools in profilers (like Instruments) 
to more easily break down profiles into "page JS" and "Gecko things".


That said, I haven't done that very much recently...

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

Re: Rust and --enable-shared-js

[Mike Hommey]

On Mon, Sep 24, 2018 at 11:04:43AM +0300, Henri Sivonen wrote:
> There's an effort to add Rust code to SpiderMonkey:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1490948
> 
> This will introduce a jsrust_shared crate that will just depend on all
> the Rust crates that SpiderMonkey needs like gkrust_shared depends on
> the crates the rest of Gecko needs.
> 
> This is fine both for building standalone SpiderMonkey (a top-level
> jsrust will produce a .a and depend on jsrust_shared) and SpiderMonkey
> as part of libxul (gkrust_shared will depend on jsrust_shared).
> 
> However, there exists a third configuration: --enable-shared-js. With
> this option, SpiderMonkey is linked dynamically instead of being baked
> into libxul. This is fine as long the set of FFI-exposing crates that
> SpiderMonkey depends on and the set of FFI-exposing crates that the
> rest of Gecko depends on are disjoint. If they aren't disjoint, a
> symbol conflict is expected.
> 
> AFAICT, this could be solved in at least three ways:
> 
>  1) Keeping the sets disjoint. If both SpiderMonkey and the rest of
> Gecko want to call the same Rust code, introduce a differently-named
> FFI binding for SpiderMonkey.
> 
>  2) Making FFI symbols .so-internal so that they don't conflict
> between shared libraries. Per
> https://bugzilla.mozilla.org/show_bug.cgi?id=1490603 , it seems that
> this would require rustc changes that don't exist yet.
> 
>  3) Dropping support for --enable-shared-js
> 
> For my immediate use case, I want to make 4 functions available both
> to SpiderMonkey and the rest of Gecko, so option #1 is feasible, but
> it won't scale. Maybe #2 becomes feasible before scaling up #1 becomes
> a problem.
> 
> But still, I'm curious:
> 
> How important is --enable-shared-js? I gather its use case is making
> builds faster for SpiderMonkey developers. Is that the only use case?

for _Gecko_ developers.

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

Rust and --enable-shared-js

[Henri Sivonen]

There's an effort to add Rust code to SpiderMonkey:
https://bugzilla.mozilla.org/show_bug.cgi?id=1490948

This will introduce a jsrust_shared crate that will just depend on all
the Rust crates that SpiderMonkey needs like gkrust_shared depends on
the crates the rest of Gecko needs.

This is fine both for building standalone SpiderMonkey (a top-level
jsrust will produce a .a and depend on jsrust_shared) and SpiderMonkey
as part of libxul (gkrust_shared will depend on jsrust_shared).

However, there exists a third configuration: --enable-shared-js. With
this option, SpiderMonkey is linked dynamically instead of being baked
into libxul. This is fine as long the set of FFI-exposing crates that
SpiderMonkey depends on and the set of FFI-exposing crates that the
rest of Gecko depends on are disjoint. If they aren't disjoint, a
symbol conflict is expected.

AFAICT, this could be solved in at least three ways:

 1) Keeping the sets disjoint. If both SpiderMonkey and the rest of
Gecko want to call the same Rust code, introduce a differently-named
FFI binding for SpiderMonkey.

 2) Making FFI symbols .so-internal so that they don't conflict
between shared libraries. Per
https://bugzilla.mozilla.org/show_bug.cgi?id=1490603 , it seems that
this would require rustc changes that don't exist yet.

 3) Dropping support for --enable-shared-js

For my immediate use case, I want to make 4 functions available both
to SpiderMonkey and the rest of Gecko, so option #1 is feasible, but
it won't scale. Maybe #2 becomes feasible before scaling up #1 becomes
a problem.

But still, I'm curious:

How important is --enable-shared-js? I gather its use case is making
builds faster for SpiderMonkey developers. Is that the only use case?
Is it being used that way in practice?

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform