Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

[Boris Zbarsky]

On 10/2/17 9:50 PM, Kris Maglione wrote:
For the pretty simple micro-benchmark below, here are the in-document 
and out-of-document numbers for three runs without the subject principal:


Sorry, I should have been clearer: I meant numbers for "inserted into 
the document" and "not inserted into the document".


Without inserting the div into the document, the numbers were closer to 
500ns, with or without the subject principal, in- or out-of-document.


Gotcha.

I just did a bit of testing with a non-inlined no-op function and it 
looks like the overhead of NeedsSubjectPrincipal is on the order of 
maybe 1-2ns.  Looks like the actual implementation we end up using 
mostly consists of reinterpret_cast, which is nice and fast.  ;) 
There's one memory read from the JSContext to get the compartment, and 
one memory read from the compartment to get the principal; as long a 
those hit cache all is good.



I haven't tested a sandbox with X-rays


Yeah, not going to be a big factor there.

Sounds to me like just using NeedsSubjectPrincipal is fine here.  Thank 
you for checking this stuff!


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

Re: Easier debugging/inspecting of remote tab state with the Browser Content Toolbox

[Bobby Holley]

Wow, this is great! I just ran into this problem a week ago and it was
quite annoying to work around. Thanks for fixing it. :-)

bholley

On Tue, Oct 3, 2017 at 4:15 PM, Matthew N.  wrote:

> With bug 1401343 
> fixed, `TabChildGlobal`s for the attached content process are exposed via a
> `tabs` getter in the Browser Content Toolbox's console tab. This makes it
> much easier to inspect a remote tab's state or to access privileged APIs
> related to remote tab content. The motivation for this change is to make it
> less tedious to inspect remote tab state with e10s, especially without
> add-on shims/CPOWs.
>
> For those of you who don't know, when the "devtools.chrome.enabled" pref is
> true the Web Developer > Browser Content Toolbox opens a toolbox targeting
> the content process that the selected tab is loaded in. From there you can
> access `tabs` in the Console tab to get an array of the `TabChildGlobal`s
> (which have access to the content Window object via `content`).
>
> Examples:
> 1) Access a ChromeOnly property on an element: `tabs[0].content.document.
> querySelector("#myEl").nodePrincipal`
> 2) Add an event listener to a tab child:
> `tabs[3].addEventListener("change", tabs[3].console.log)`
>
> Bug 1346316  tracks
> giving easier access to the selected tab's TabChildGlobal and making the
> frame picker work (to more easily change between `TabChildGlobal`s by URL).
>
> Happy debugging!
> Matthew Noorenberghe (:MattN)
> ___
> 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: Easier debugging/inspecting of remote tab state with the Browser Content Toolbox

[Matthew N.]

On 2017-10-03 5:44 PM, Boris Zbarsky wrote:

On 10/3/17 7:15 PM, Matthew N. wrote:
For those of you who don't know, when the "devtools.chrome.enabled" 
pref is
true the Web Developer > Browser Content Toolbox opens a toolbox 
targeting

the content process that the selected tab is loaded in.


Matt,

Do you know whether this starts a new Firefox instance, like the Browser 
Toolbox?


I don't believe it does since the the Browser Content Toolbox opens as a 
window in the regular chrome UI process.


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

Re: Easier debugging/inspecting of remote tab state with the Browser Content Toolbox

[Boris Zbarsky]

On 10/3/17 7:15 PM, Matthew N. wrote:

For those of you who don't know, when the "devtools.chrome.enabled" pref is
true the Web Developer > Browser Content Toolbox opens a toolbox targeting
the content process that the selected tab is loaded in.


Matt,

Do you know whether this starts a new Firefox instance, like the Browser 
Toolbox?


If it does, folks should be aware that doing this after your Firefox has 
downloaded an update will crash your browser (the entire thing, not just 
some tabs) at some random later point.  :( See 
https://bugzilla.mozilla.org/show_bug.cgi?id=1366808#c18


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

Re: Intent to unship: :-moz-system-metric pseudo-class and media queries in content pages.

[Xidorn Quan]

On Sat, Sep 2, 2017, at 06:06 AM, Emilio Cobos Álvarez wrote:
> Hi dev-platform@,
> 
> I'd like to unship access to the :-moz-system-metric pseudo-class, and
> the system metric media queries, from content pages. I just filed
>  for that.
> 
> They're not in any spec, and they seem unused (I can't find anything
> non-mozilla-related in Github code search). Furthermore they expose
> system information, which can be a fingerprinting vector, and pretty
> random stuff like "is a color picker available?".
> 
> According to Boris it predates Gecko's capacity to not expose stuff.
> 
> I think it should be pretty safe to unship, but let me know if you don't
> think that way, or have data that indicates the opposite.
> 
> The intention is to do that in Firefox 58, given we don't want to add
> extra risk to Stylo.

To make things clear, this bug is going to unship the pseudo-class
:-moz-system-metric and the following media queries from content page:
* -moz-color-picker-available
* -moz-scrollbar-start-backward
* -moz-scrollbar-start-forward
* -moz-scrollbar-end-backward
* -moz-scrollbar-end-forward
* -moz-scrollbar-thumb-proportional
* -moz-overlay-scrollbars
* -moz-windows-default-theme
* -moz-mac-graphite-theme
* -moz-mac-yosemite-theme
* -moz-windows-accent-color-in-titlebar
* -moz-windows-compositor
* -moz-windows-classic
* -moz-windows-glass
* -moz-menubar-drag
* -moz-windows-theme
* -moz-os-version
* -moz-swipe-animation-enabled
* -moz-physical-home-button
* -moz-is-glyph

Mostly of them will still be available in UA sheets and chrome
documents. -moz-physical-home-button may be removed completely as it is
just a leftover from B2G.

emilio's current patch also includes unshipping -moz-touch-enabled, but
I don't think we should do that until we implement the standard
equivalent of this media query in bug 1035774.

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

Easier debugging/inspecting of remote tab state with the Browser Content Toolbox

[Matthew N.]

With bug 1401343 
fixed, `TabChildGlobal`s for the attached content process are exposed via a
`tabs` getter in the Browser Content Toolbox's console tab. This makes it
much easier to inspect a remote tab's state or to access privileged APIs
related to remote tab content. The motivation for this change is to make it
less tedious to inspect remote tab state with e10s, especially without
add-on shims/CPOWs.

For those of you who don't know, when the "devtools.chrome.enabled" pref is
true the Web Developer > Browser Content Toolbox opens a toolbox targeting
the content process that the selected tab is loaded in. From there you can
access `tabs` in the Console tab to get an array of the `TabChildGlobal`s
(which have access to the content Window object via `content`).

Examples:
1) Access a ChromeOnly property on an element: `tabs[0].content.document.
querySelector("#myEl").nodePrincipal`
2) Add an event listener to a tab child:
`tabs[3].addEventListener("change", tabs[3].console.log)`

Bug 1346316  tracks
giving easier access to the selected tab's TabChildGlobal and making the
frame picker work (to more easily change between `TabChildGlobal`s by URL).

Happy debugging!
Matthew Noorenberghe (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Chris Peterson]

On 2017-10-03 2:18 PM, Boris Zbarsky wrote:
Right now, at 60px, I can see 7-10 chars in a tab title.  This is 
sometimes (but not always) enough for me to make sense of what I'm 
looking at when the favicon is not helpful.  For example, for bugzilla 
bugs I can see the whole bug number.


In the new setup is sounds like I will see 1-2 chars.  At that point, 
it's not immediately clear to me that there's any value to not just 
setting the min-width to "40px" and allowing all the title text to 
disappear altogether.  There is definite value in not going below the 
"keep the favicon entirely visible" value, of course.


I think tab bar usability would be much improved if the tab bar's 
drop-down list of full tab titles was always available. This is the "V" 
button that appears to the right of the "+" tab button.


On my machine, the drop-down list button only appears after 15 tabs are 
open, but (as Boris points out) the tabs stopped being identifiable 
before 15 tabs were open.

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

Re: --verify option added to mochitest, reftest, xpcshell test harnesses

[Geoffrey Brown]

On Tue, Oct 3, 2017 at 1:05 PM, Andrew Halberstadt
 wrote:
> This is really great Geoff! Hopefully it can cut down the number of new
> intermittents we introduce to the tree. Do you know if orangefactor or
> ActiveData can track the rate of new incoming intermittents? Would be neat
> to see how much of an impact this tool has on that.

Thanks Andrew.

I think that data is probably available in ActiveData, but querying
for "new" might be tricky...I wouldn't know where to begin.

Bugzilla might be the way to go: count bugs with keyword
intermittent-failure created today, vs yesterday vs the day before
...?

I suspect those numbers would be dominated by low frequency
intermittent failures, which might not change. In fact I'm actually
hoping to catch only mid- to high-frequency failures with TV, so that
it doesn't end up wasting people's time fixing intermittents that we
would hardly notice otherwise.

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

Re: Changes to tab min-width

[Myk Melez]

Jeff Griffiths wrote:

1. do you prefer the existing behaviour or the new behaviour?

I prefer the new behavior.


2. if you prefer a value for this pref different than 50 or 100, what
is it? Why?
I prefer a value of 0 (i.e. truly infinite tabs, never scrolling), 
because I distinguish tabs by their positions as much as (if not more so 
than) their labels, and showing all tabs fixes their positions, making 
them much easier to find again and click on, even with only a hazy 
recollection of where they are.


(Tabs do move a bit as other tabs are added/removed, but this movement 
is much slighter than that induced by scrolling, and they still stay in 
the same area of the screen.)


Also, when I'm traversing to a far-away tab, especially when using 
keyboard shortcuts, showing all tabs enables me to "see ahead" and 
locate the target tab with my eyes in time to slow down and stop on it 
with my fingers. With scrolling tabs, however, when far-away tabs are 
offscreen, I tend to overshoot the target and have to backtrack.


Back when we introduced scrolling, I set the preference to minimize it. 
Then, when the preference stopped working, I learned to live with 
scrolling tabs. But I still find it cumbersome and would prefer to 
disable tab scrolling.


I recall that Aza Raskin made some similar points back when we 
introduced scrolling. I think this was his blog post on the subject:


http://www.azarask.in/blog/post/firefox_20_tabs_gone_wrong/


One aspect that I would like to stress about this change: most
existing Firefox users will never see it, because they are unlikely to
open m,ore than 10 tabs at any one time. So what we are really talking
about is a change that will trade being able to see more tabs vs being
able to read more text in each tab title.
I'm actually the common case most of the time. I don't hoard tabs, and I 
close all tabs (except a small set of pinned tabs) after each browsing 
"session", which lasts anywhere from a few minutes to a few hours (or on 
very rare occasions, days). So I don't usually have more than a handful 
of tabs open.


But occasionally I do research that prompts me to open 20-40 tabs and 
then jump back and forth between them (f.e. when shopping for a product 
for which there are many choices, or when investigating a complex 
technical issue in our products). And that's when the tab overflow 
behavior makes a difference.


-myk

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

Re: Changes to tab min-width

[Boris Zbarsky]

On 10/3/17 4:36 PM, Jeff Griffiths wrote:

2. it sets the default value of the tab to 50, previously this value
was hard-coded at 100.


Jeff,

So just to make sure I understand the change (and this is a theoretical 
point, because I haven't had a chance to try the change yet)...  Right 
now, the min tab width is 100.  This contains the following pieces:


1)  18px of horizontal padding (on the .tab-content).
2)  16px of favicon.
3)   6px of favicon right-margin.
4)  60px of space for the page title.

With the new setup, just looking at the patch, the main thing that 
changes is that the page title space drops from 60px to 10px when enough 
tabs are open, because none of the other values change, right?


Right now, at 60px, I can see 7-10 chars in a tab title.  This is 
sometimes (but not always) enough for me to make sense of what I'm 
looking at when the favicon is not helpful.  For example, for bugzilla 
bugs I can see the whole bug number.


In the new setup is sounds like I will see 1-2 chars.  At that point, 
it's not immediately clear to me that there's any value to not just 
setting the min-width to "40px" and allowing all the title text to 
disappear altogether.  There is definite value in not going below the 
"keep the favicon entirely visible" value, of course.



We looked into this and I generally agree with the
comments: chrome's "infinite tabs visible" approach results in a much
higher usable/visible


I think there's a difference here between "usable" and "visible" 
And yes, I understand that I can just set the pref as needed.



One aspect that I would like to stress about this change: most
existing Firefox users will never see it, because they are unlikely to
open m,ore than 10 tabs at any one time.


Just fwiw, at the 100px width, tabstrip scrolling kicks in for me at 9 
tabs.  It's possible that most of our users have wider windows than 
mine, of course.


I will definitely try experimenting a bit with this pref to see how 
things behave in practice.


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

Re: Intent to implement: CSS media queries, interaction media features

[twisniewski]

> Will those measures be part of the work done (enabled only when 
> privacy.resistFingerprinting is set)?

If we want them to be, sure. I don't mind adding a patch to do so as part of 
the initial landing rather than a follow-up.

Bear in mind that I'm operating on the presumption that we would want 
anti-fingerprinting to always return values for Windows/OSX/Linux that convey 
there is only a fine, hover-capable pointer (a mouse), and on Android to convey 
that there is only a coarse, non-hover-capable pointer (a touchscreen). If 
that's not good, then please let me know.

>Note that the system metric media queries respond to the
privacy.resistFingerprinting pref. I think we should keep doing the same
for this one.

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

Re: Intent to implement: CSS media queries, interaction media features

[Emilio Cobos Álvarez]

On 10/03/2017 10:12 PM, Thomas Wisniewski wrote:> Security & Privacy
Concerns: this exposes whether the user has pointer that
> is finely controlled like a mouse, or more coarse-grained like a
> touchscreen (or no pointer at all). It also exposes whether they have a
> pointer capable of "hover" effects (like a mouse). This lets sites
> distinguish between the user having a mouse-like device or touchscreen-like
> device, and potentially other devices like stylii. It exposes a little more
> fingerprintable information than -moz-touch-enabled, however it would be
> trivial for anti-fingerprinting measures to always return a specific set of
> values for mobiles vs desktops.

Note that the system metric media queries respond to the
privacy.resistFingerprinting pref. I think we should keep doing the same
for this one.

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

Re: Intent to implement: CSS media queries, interaction media features

[Tom Ritter]

On Tue, Oct 3, 2017 at 3:12 PM, Thomas Wisniewski  wrote:
> Security & Privacy Concerns: this exposes whether the user has pointer that
> is finely controlled like a mouse, or more coarse-grained like a
> touchscreen (or no pointer at all). It also exposes whether they have a
> pointer capable of "hover" effects (like a mouse). This lets sites
> distinguish between the user having a mouse-like device or touchscreen-like
> device, and potentially other devices like stylii. It exposes a little more
> fingerprintable information than -moz-touch-enabled, however it would be
> trivial for anti-fingerprinting measures to always return a specific set of
> values for mobiles vs desktops.

Will those measures be part of the work done (enabled only when
privacy.resistFingerprinting is set)?

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

Changes to tab min-width

[Jeff Griffiths]

Hi!

tl;dr we changed the default pixel value at which we overflow tabs,
and I want your feedback.

We just added a change to m-c[1] that does to things:

1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that
contains a pixel value that controls the minimum width of a tab.

2. it sets the default value of the tab to 50, previously this value
was hard-coded at 100.

Work is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1404465

We did this based on some early feedback from a few different sources
that people coming from chrome ( or in some cases, existing users )
thought that the Firefox behaviour of scrolling the tabstrip was
off-putting. We looked into this and I generally agree with the
comments: chrome's "infinite tabs visible" approach results in a much
higher usable/visible tab count in a given window than ours does. This
change puts us roughly at par.

To put this in numbers:
 * in chrome I can open ~ 24 tabs before the tabstrip's usability is
degraded a lot
 * in current firefox, I can open ~ 12 tabs before tabstrip scrolling kicks in
 * with this change applied I can open 25 tabs with the pref value set to 50px

( Caveats: this was on the built-in display on my Macbook Pro with the
default theme, your mileage may vary, etc )

I want feedback on this change from these lists, and will also be
looking for feedback from the original sources of this complaint. In
particular:

1. do you prefer the existing behaviour or the new behaviour?
2. if you prefer a value for this pref different than 50 or 100, what
is it? Why?

One aspect that I would like to stress about this change: most
existing Firefox users will never see it, because they are unlikely to
open m,ore than 10 tabs at any one time. So what we are really talking
about is a change that will trade being able to see more tabs vs being
able to read more text in each tab title.

Moving forward there are a few different options:

1. uplifting this change into 57 ( possibly with a different default
value ) If we think the patch has a generally positive effect and no
downsides, we may decide to uplift into 57 Beta and let it ride the
trains.

2. keeping the change in 58, possibly with a different value.

3. keeping the change in 58, preserving the current setting of 100px
and providing an alternate pref ( probably a toggle or predefined
values ) for "skinnier" tabs.

Longer term I intend to propose a more in-depth study of tab behaviour
among different user segments and assess different strategies for
heavier tab users including things like horizontal tab scaling,
vertical tabs, etc. I can't see that happening before Q1 next year.

cheers, Jeff

[1] https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: CSS media queries, interaction media features

[Thomas Wisniewski]

Summary: Implement the CSS features [any-]pointer:{none|coarse|fine} and
[any-]hover:{none|hover} in a manner that is compatible with Blink. These
features are implemented in all other major engines including Edge, and
sites like Gmail are now using them. Our lack of support for these features
has also caused some developer friction, especially since our proprietary
-moz-touch-enabled feature seems to have flown completely under the radar.

Bug: 1035774

Link to standard: https://dev.w3.org/csswg/mediaqueries4/#mf-interaction

Platform coverage: Windows, OSX, Linux and Android (though OSX/Cocoa seems
to have no APIs to expose this information, so we will fall back to the
same "user only has a mouse" values that Blink and WebKit use on OSX).

Estimated or target release: Firefox 58.

Preference behind which this will be implemented:: None.

Is this feature enabled by default in sandboxed iframes? Yes.

Tests: only for the CSS parsing (similar to how -moz-touch-enabled is
currently tested). We do not currently have any testing infrastructure to
mock the OS calls for full test coverage. Nor do the Web Platform Tests
(and there are no bugs yet made against the WPTs to add them). Given that
other vendors have long shipped this regardless, and there have been no
major interop issues, I don't suspect this needs to be blocked on such
tests.

How stable is the spec: the last point of contention that I'm aware of was
resolved by other vendors a year ago when the "on-demand" feature was
dropped from the draft spec.

Security & Privacy Concerns: this exposes whether the user has pointer that
is finely controlled like a mouse, or more coarse-grained like a
touchscreen (or no pointer at all). It also exposes whether they have a
pointer capable of "hover" effects (like a mouse). This lets sites
distinguish between the user having a mouse-like device or touchscreen-like
device, and potentially other devices like stylii. It exposes a little more
fingerprintable information than -moz-touch-enabled, however it would be
trivial for anti-fingerprinting measures to always return a specific set of
values for mobiles vs desktops.

Web designer / developer use-cases: Allowing sites to definitively know
whether the user has a touch-capable device, mouse-like device, or
stylus-like device (or all three), so that appropriate styles can be served
for each case without having to resort to flimsier scripts to guess at
those capabilities.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: --verify option added to mochitest, reftest, xpcshell test harnesses

[Andrew Halberstadt]

This is really great Geoff! Hopefully it can cut down the number of new
intermittents we introduce to the tree. Do you know if orangefactor or
ActiveData can track the rate of new incoming intermittents? Would be neat
to see how much of an impact this tool has on that.

On Mon, Oct 2, 2017 at 1:08 PM Geoffrey Brown  wrote:

> The mochitest, reftest, and xpcshell test harnesses now support a
> --verify option. For example:
>
>   mach mochitest
> docshell/test/test_anchor_scroll_after_document_open.html --verify
>
> In verify mode, the requested test is run multiple times, in various
> "modes", in hopes of quickly finding any intermittent failures. Once
> tests are complete, a summary of results is printed:
>
> :::
> ::: Test verification summary for:
> :::
> ::: docshell/test/test_anchor_scroll_after_document_open.html
> :::
> ::: 1. Run each test 10 times in one browser. : Pass
> ::: 2. Run each test 5 times in a new browser each time. : Pass
> ::: 3. Run each test 10 times in one browser, in chaos mode. : Pass
> ::: 4. Run each test 5 times in a new browser each time, in chaos mode. :
> Pass
> :::
> ::: Test verification PASSED
> :::
>
> There's no flexibility in the number of times the test is run in each
> mode and that's by design: I wanted a simple, standard way of checking
> "Is this test likely to produce a frequent intermittent failure"?
>
> Verify mode was developed for the test-verify task (announcement
> coming soon!) but it may also be a convenient addition to your local
> testing.
>
> More info at [1]. Bug and enhancement requests welcomed: please file
> bugs blocking bug 1357513.
>
> [1] https://developer.mozilla.org/en-US/docs/Test_Verification
> ___
> 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: Containers graduation from Test Pilot - we still care about 57+

[Andrew McKay]

Just to close the loop on this thread, in 57 this will no longer
disable multi-e10s.

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

Thanks for the heads up Ben.

On 27 September 2017 at 10:53, Ben Kelly  wrote:
> It disables multi-e10s.  Forced to one content process.
>
> On Sep 27, 2017 12:58 PM, "Andrew McKay"  wrote:
>
> Sorry, it disables e10s even though it has
> true in the
> install.rdf? That shouldn't be the case.
>
> On 27 September 2017 at 07:14, Ben Kelly  wrote:
>> On Mon, Sep 25, 2017 at 9:28 AM, Ben Kelly  wrote:
>>
>>> Thanks Jonathan.
>>>
>>> Also, it seems the link to the web extension version of the container
>>> addon is broken above.  This one works for me:
>>>
>>> https://github.com/mozilla/multi-account-containers/releases/latest
>>>
>>
>> Sorry, I guess this isn't a web extension yet.  Its a legacy addon and
>> therefore disables multi-e10s.
>> ___
>> 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: --verify option added to mochitest, reftest, xpcshell test harnesses

[Mike Conley]

This is super cool! Thanks Geoffrey!

On 2017-10-02 1:08 PM, Geoffrey Brown wrote:
> The mochitest, reftest, and xpcshell test harnesses now support a
> --verify option. For example:
> 
>   mach mochitest
> docshell/test/test_anchor_scroll_after_document_open.html --verify
> 
> In verify mode, the requested test is run multiple times, in various
> "modes", in hopes of quickly finding any intermittent failures. Once
> tests are complete, a summary of results is printed:
> 
> :::
> ::: Test verification summary for:
> :::
> ::: docshell/test/test_anchor_scroll_after_document_open.html
> :::
> ::: 1. Run each test 10 times in one browser. : Pass
> ::: 2. Run each test 5 times in a new browser each time. : Pass
> ::: 3. Run each test 10 times in one browser, in chaos mode. : Pass
> ::: 4. Run each test 5 times in a new browser each time, in chaos mode. : Pass
> :::
> ::: Test verification PASSED
> :::
> 
> There's no flexibility in the number of times the test is run in each
> mode and that's by design: I wanted a simple, standard way of checking
> "Is this test likely to produce a frequent intermittent failure"?
> 
> Verify mode was developed for the test-verify task (announcement
> coming soon!) but it may also be a convenient addition to your local
> testing.
> 
> More info at [1]. Bug and enhancement requests welcomed: please file
> bugs blocking bug 1357513.
> 
> [1] https://developer.mozilla.org/en-US/docs/Test_Verification
> ___
> 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

Pre-commit hook for adding new FTL localization files

[zbraniecki]

Hi all,

tl;dr - This will almost certainly not affect your work. We're adding a 
temporary pre-commit hook that requires L10n Drivers to r+ any patches that 
touch .ftl files.



As the waters calm down after 57 cycle, we're getting ready to start enabling 
the new localization API in Gecko. You've probably heard about it under the 
project code name L20n, while the API itself is named Fluent [0].

It's a big project and we are going to release it in multiple stages before we 
feel comfortable enough to enable everyone to use it.

At the core of it is a new localization file format that will replace .DTD and 
.properties. It uses extension `.ftl` which stands for `Fluent Translation 
List`.

In order to increase our ability to control the landing approach, we're going 
to land a new hook that will reject any patch that touches an .ftl file and 
doesn't have r+ from the following people:

 - :flod
 - :gandalf
 - :pike
 - :stas

This should not affect your work in any way, since over the next month or so 
we'll be only manually transitioning single files from obscure UI elements to 
minimize the risk and test-drive the new platform.

The bug for adding the hook is 
https://bugzilla.mozilla.org/show_bug.cgi?id=1394891

By All Hands we hope to be ready to remove the hook and enable everyone to use 
the new API. In the months to come, we'll be writing guidelines, tutorials, 
blog posts and other forms of prose[1] to get you all familiar with what 
changes and how to review patches for the new system.

Stay tuned!

zb.

[0] http://projectfluent.io/
[1] We're looking for skilled rappers and haiku artists with experience in tech 
rhymes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform