Re: Dump frame tree in real time

[Jip de Beer]

Thanks for the reply. My problem with display lists is that they only contain 
this information about nodes within the viewport. I'm interested in all nodes 
that take up space within the document.

I know Firefox can calculate the necessary information for nodes outside of the 
viewport because I can take a screenshot of the entire page with 
CanvasRenderingContext2D.drawWindow() and it correctly renders the entire page 
(also outside of the viewport).

I don't follow you entirely on this:
> The answer, in general, is that two nodes may not be "in front" of each other 
> at all.

Document.elementsFromPoint() can return all nodes at a specific coordinate in 
'visual order'. It returns which elements are in front of others. But this is 
again restricted to the viewport and I don't want it for a specific coordinate, 
but for all nodes within the document.

On Thursday, 14 April 2016 18:03:11 UTC+2, Boris Zbarsky  wrote:
> On 4/14/16 10:52 AM, Jip de Beer wrote:
> > The Frame Dump doesn't contain any information about z-order.
> 
> That information is not stored in the frame tree, really.  It's computed 
> during display list construction.
> 
> > How can I know which nodes are in front of other nodes?
> 
> The answer, in general, is that two nodes may not be "in front" of each 
> other at all.  That is, parts of one node may be in front of parts of 
> the other while other parts are behind it.
> 
> -Boris


On Thursday, 14 April 2016 18:03:11 UTC+2, Boris Zbarsky  wrote:
> On 4/14/16 10:52 AM, Jip de Beer wrote:
> > The Frame Dump doesn't contain any information about z-order.
> 
> That information is not stored in the frame tree, really.  It's computed 
> during display list construction.
> 
> > How can I know which nodes are in front of other nodes?
> 
> The answer, in general, is that two nodes may not be "in front" of each 
> other at all.  That is, parts of one node may be in front of parts of 
> the other while other parts are behind it.
> 
> -Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Engineering Productivity Q1 Update

[Nicholas Nethercote]

Great stuff all around! Thank you for the update.

Nick

On Fri, Apr 15, 2016 at 4:07 AM, Jonathan Griffin  wrote:
> Engineering Productivity is off to a great start in 2016; here’s what we’ve
> been up to in Q1.
> Build System
>
> Build system improvements are a major priority for Engineering Productivity
> in 2016. The build team made great progress in Q1:
>
>
>-
>
>Windows builds are now made using VS2015. This shaves 100 minutes off of
>PGO builds!
>-
>
>Install manifest processing is up to 10x faster on Windows (10s now vs
>100s before). Tests files are now lazily installed, making builds and test
>invocation significantly faster.
>-
>
>Many improvements to artifact builds, which have resulted in a 50% speed
>improvement
>-
>
>Artifact builds now support git-cinnabar users
>-
>
>A lot of work has been done to migrate legacy Makefiles to moz.build
>files, and to move away from autoconf; more along these lines will be done
>in Q2
>-
>
>Build telemetry has been added, which will allow us to track
>improvements for developer builds; this is currently opt-in, so please
>consider setting BUILD_SYSTEM_TELEMETRY=1 in your build environment to help
>us validate this
>-
>
>The ICU build system has been reimplemented so it no longer excessively
>slows down builds.
>
>
> The build team is a large meta-team comprised of individuals from
> Engineering Productivity and several other teams; thanks to everyone who
> has contributed.
> MozReview and Autoland
>
> The primary goal of the MozReview team in Q1 was to increase user adoption
> by addressing various UX issues that have confused or frustrated users. To
> that end, a feedback panel consisting of some of Mozilla’s top reviewers
> has been created to provide a feedback loop for the MozReview developers.
> We’ve identified a number of issues that impact reviewer productivity and
> are working on them, starting with the top issue: lack of inline comments
> in the diff viewer. We also explored confusion around the general layout
> and flow of MozReview/Review Board, and working with UX designer Tiffanie
> Shakespeare we’re coming up with some big changes that should improve
> general usability. We have been working on a framework that will allow us
> to experiment in the UI without having to completely fork Review Board.
>
> In addition, this quarter we implemented various high-priority fixes and
> improvements, including
>
>
>-
>
>Disabling interdiff rebase filtering, since it was unreliable.
>-
>
>Adding options to disable reviewer deduction and to publish without
>prompting when pushing commits up.
>-
>
>Concatenating MozReview BMO-comment emails to reduce the volume of email
>sent out when many commits are published.
>-
>
>Adding extra context to the diffs in BMO comments.
>-
>
>Showing a comment button when hovering over the diff viewer, improving
>discoverability.
>-
>
>Clarifying status of reviewers in the commits table.
>
>
> We’re also very close to landing two other important features: switching
> from “ship it” to the standard BMO review flags (r?/r+/r-), and letting
> reviewers delegate reviews to others.
>
>
> Finally, autoland-to-inbound was rolled out, giving MozReview users an easy
> way to land reviewed patches.
> TaskCluster Migration
>
> Engineering Productivity is helping the TaskCluster team and Release
> Engineering migrate builds and automated tests from buildbot to
> TaskCluster. In Q1, this involved a lot of work in crafting a docker image
> that could be used to run linux64 debug unit tests successfully, and
> related work in greening up the test suites in that environment. Linux64
> builds and tests in TaskCluster are now running as Tier 1 in Treeherder, so
> the teams are moving on to other linux64 flavors: opt, pgo, and asan.
>
> Performance Automation
>
> Sheriffing of performance regressions of Talos tests has moved entirely to
> Perfherder; Talos no longer reports data to graphserver, and graphserver
> will be retired in the future. Perfherder also now displays performance
> metrics generated by AreWeFastYet  and
> AreWeSlimYet .
>
> To support the e10s project, Perfherder now has an e10s dashboard
>  that can be used to view
> the differences between e10s and non-e10s Talos tests.
>
> Finally, performance benchmarks previously running in Mozbench have been
> migrated to AreWeFastYet, and Mozbench has been retired.
> Continuous Integration
>
> A lot of work has been completed to support the addon signing project; this
> includes taking all of the addons used by test automation and either
> converting them to restartless addons and making them get installed via a
> new API, or signing them in-tree. All test harnesses now work with addon
> signing enforced.
>
> For e10s, all appropri

Re: Engineering Productivity Q1 Update

[Ivan Enderlin]

Congrats! Impressive results. Thanks for your work.

On 14/04/16 20:07, Jonathan Griffin wrote:

Engineering Productivity is off to a great start in 2016; here’s what we’ve
been up to in Q1.
Build System

Build system improvements are a major priority for Engineering Productivity
in 2016. The build team made great progress in Q1:


-

Windows builds are now made using VS2015. This shaves 100 minutes off of
PGO builds!
-

Install manifest processing is up to 10x faster on Windows (10s now vs
100s before). Tests files are now lazily installed, making builds and test
invocation significantly faster.
-

Many improvements to artifact builds, which have resulted in a 50% speed
improvement
-

Artifact builds now support git-cinnabar users
-

A lot of work has been done to migrate legacy Makefiles to moz.build
files, and to move away from autoconf; more along these lines will be done
in Q2
-

Build telemetry has been added, which will allow us to track
improvements for developer builds; this is currently opt-in, so please
consider setting BUILD_SYSTEM_TELEMETRY=1 in your build environment to help
us validate this
-

The ICU build system has been reimplemented so it no longer excessively
slows down builds.


The build team is a large meta-team comprised of individuals from
Engineering Productivity and several other teams; thanks to everyone who
has contributed.
MozReview and Autoland

The primary goal of the MozReview team in Q1 was to increase user adoption
by addressing various UX issues that have confused or frustrated users. To
that end, a feedback panel consisting of some of Mozilla’s top reviewers
has been created to provide a feedback loop for the MozReview developers.
We’ve identified a number of issues that impact reviewer productivity and
are working on them, starting with the top issue: lack of inline comments
in the diff viewer. We also explored confusion around the general layout
and flow of MozReview/Review Board, and working with UX designer Tiffanie
Shakespeare we’re coming up with some big changes that should improve
general usability. We have been working on a framework that will allow us
to experiment in the UI without having to completely fork Review Board.

In addition, this quarter we implemented various high-priority fixes and
improvements, including


-

Disabling interdiff rebase filtering, since it was unreliable.
-

Adding options to disable reviewer deduction and to publish without
prompting when pushing commits up.
-

Concatenating MozReview BMO-comment emails to reduce the volume of email
sent out when many commits are published.
-

Adding extra context to the diffs in BMO comments.
-

Showing a comment button when hovering over the diff viewer, improving
discoverability.
-

Clarifying status of reviewers in the commits table.


We’re also very close to landing two other important features: switching
from “ship it” to the standard BMO review flags (r?/r+/r-), and letting
reviewers delegate reviews to others.


Finally, autoland-to-inbound was rolled out, giving MozReview users an easy
way to land reviewed patches.
TaskCluster Migration

Engineering Productivity is helping the TaskCluster team and Release
Engineering migrate builds and automated tests from buildbot to
TaskCluster. In Q1, this involved a lot of work in crafting a docker image
that could be used to run linux64 debug unit tests successfully, and
related work in greening up the test suites in that environment. Linux64
builds and tests in TaskCluster are now running as Tier 1 in Treeherder, so
the teams are moving on to other linux64 flavors: opt, pgo, and asan.

Performance Automation

Sheriffing of performance regressions of Talos tests has moved entirely to
Perfherder; Talos no longer reports data to graphserver, and graphserver
will be retired in the future. Perfherder also now displays performance
metrics generated by AreWeFastYet  and
AreWeSlimYet .

To support the e10s project, Perfherder now has an e10s dashboard
 that can be used to view
the differences between e10s and non-e10s Talos tests.

Finally, performance benchmarks previously running in Mozbench have been
migrated to AreWeFastYet, and Mozbench has been retired.
Continuous Integration

A lot of work has been completed to support the addon signing project; this
includes taking all of the addons used by test automation and either
converting them to restartless addons and making them get installed via a
new API, or signing them in-tree. All test harnesses now work with addon
signing enforced.

For e10s, all appropriate test suites have been enabled in e10s mode on
Windows 7 on trunk, with the exception of a couple of suites on Windows 7
debug, due to ongoing assertions and leaks. All suites are running in e

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Jason Duell]

On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson 
wrote:

>
> Focusing on third-party session cookies is an interesting idea.
> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
> content problems. Much later, we could consider sessionizing even HTTPS
> third-party cookies.
>

How about we sessionize only 3rd party HTTP cookies from sites that are on
our tracking protection list?  That seems the most targeted way to
encourage ad networks to bump up to HTTPS with a minimal amount of
collateral damage to other users of 3rd party HTTP cookies.

> We seem to have this already: network.cookie.thirdparty.sessionOnly

Correct, that's what it does.

Jason



>
> On 4/14/16 1:54 AM, Chris Peterson wrote:
>
>> Summary: Treat cookies set over non-secure HTTP as session cookies
>>
>> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
>> cookies without the `secure` flag as session cookies.
>>
>> PROS:
>>
>> * Security: login cookies set over non-secure HTTP can be sniffed and
>> replayed. Clearing those cookies at the end of the browser session would
>> force the user to log in again next time, reducing the window of
>> opportunity for an attacker to replay the login cookie. To avoid this,
>> login-requiring sites should use HTTPS for at least their login page
>> that set the login cookie.
>>
>> * Privacy: most ad networks still use non-secure HTTP. Content sites
>> that use these ad networks are prevented from deploying HTTPS themselves
>> because of HTTP/HTTPS mixed content breakage. Clearing user-tracking
>> cookies set over non-secure HTTP at the end of every browser session
>> would be a strong motivator for ad networks to upgrade to HTTPS, which
>> would unblock content sites' HTTPS rollouts.
>>
>> However, my testing of Henri's original proposal shows that too few
>> sites set the `secure` cookie flag for this to be practical. Even sites
>> that primarily use HTTPS, like google.com, omit the `secure` flag for
>> many cookies set over HTTPS.
>>
>> Instead, I propose treating all cookies set over non-secure HTTP as
>> session cookies, regardless of whether they have the `secure` flag.
>> Cookies set over HTTPS would be treated as "secure so far" and allowed
>> to persist beyond the current browser session. This approach could be
>> tightened so any "secure so far" cookies later sent over non-secure HTTP
>> could be downgraded to session cookies. Note that Firefox's session
>> restore will persist "session" cookies between browser restarts for the
>> tabs that had been open. (This is "eternal session" feature/bug 530594.)
>>
>> To test my proposal, I loaded the home pages of the Alexa Top 25 News
>> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
>> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
>> cookies. Treating non-secure cookies as session cookies means that over
>> 1100 cookies would be cleared at the end of the browser session!
>>
>> CONS:
>>
>> * Sites that allow users to configure preferences without logging into
>> an account would forget the users' preferences if they are not using
>> HTTPS. For example, companies that have regional sites would forget the
>> user's selected region at the end of the browser session.
>>
>> * Ad networks' opt-out cookies (for what they're worth) set over
>> non-secure HTTP would be forgotten at the end of the browser session.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>>
>> Link to standard: N/A
>>
>> Platform coverage: All platforms
>>
>> Estimated or target release: Firefox 49
>>
>> Preference behind which this will be implemented:
>> network.cookie.lifetime.httpSessionOnly
>>
>> Do other browser engines implement this? No
>>
>> [1]
>>
>> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
>>
>> [2] http://www.alexa.com/topsites/category/Top/News
>>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

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

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Jason Duell]

On Fri, Apr 15, 2016 at 2:12 AM, Jason Duell  wrote:

> On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson 
> wrote:
>
>>
>> Focusing on third-party session cookies is an interesting idea.
>> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
>> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
>> content problems. Much later, we could consider sessionizing even HTTPS
>> third-party cookies.
>>
>
> How about we sessionize only 3rd party HTTP cookies from sites that are on
> our tracking protection list?  That seems the most targeted way to
> encourage ad networks to bump up to HTTPS with a minimal amount of
> collateral damage to other users of 3rd party HTTP cookies.
>

(We could presumably keep a list of CDNs too and sessionize those as well)

Jason



> > We seem to have this already: network.cookie.thirdparty.sessionOnly
>
> Correct, that's what it does.
>
> Jason
>
>
>
>>
>> On 4/14/16 1:54 AM, Chris Peterson wrote:
>>
>>> Summary: Treat cookies set over non-secure HTTP as session cookies
>>>
>>> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
>>> cookies without the `secure` flag as session cookies.
>>>
>>> PROS:
>>>
>>> * Security: login cookies set over non-secure HTTP can be sniffed and
>>> replayed. Clearing those cookies at the end of the browser session would
>>> force the user to log in again next time, reducing the window of
>>> opportunity for an attacker to replay the login cookie. To avoid this,
>>> login-requiring sites should use HTTPS for at least their login page
>>> that set the login cookie.
>>>
>>> * Privacy: most ad networks still use non-secure HTTP. Content sites
>>> that use these ad networks are prevented from deploying HTTPS themselves
>>> because of HTTP/HTTPS mixed content breakage. Clearing user-tracking
>>> cookies set over non-secure HTTP at the end of every browser session
>>> would be a strong motivator for ad networks to upgrade to HTTPS, which
>>> would unblock content sites' HTTPS rollouts.
>>>
>>> However, my testing of Henri's original proposal shows that too few
>>> sites set the `secure` cookie flag for this to be practical. Even sites
>>> that primarily use HTTPS, like google.com, omit the `secure` flag for
>>> many cookies set over HTTPS.
>>>
>>> Instead, I propose treating all cookies set over non-secure HTTP as
>>> session cookies, regardless of whether they have the `secure` flag.
>>> Cookies set over HTTPS would be treated as "secure so far" and allowed
>>> to persist beyond the current browser session. This approach could be
>>> tightened so any "secure so far" cookies later sent over non-secure HTTP
>>> could be downgraded to session cookies. Note that Firefox's session
>>> restore will persist "session" cookies between browser restarts for the
>>> tabs that had been open. (This is "eternal session" feature/bug 530594.)
>>>
>>> To test my proposal, I loaded the home pages of the Alexa Top 25 News
>>> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
>>> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
>>> cookies. Treating non-secure cookies as session cookies means that over
>>> 1100 cookies would be cleared at the end of the browser session!
>>>
>>> CONS:
>>>
>>> * Sites that allow users to configure preferences without logging into
>>> an account would forget the users' preferences if they are not using
>>> HTTPS. For example, companies that have regional sites would forget the
>>> user's selected region at the end of the browser session.
>>>
>>> * Ad networks' opt-out cookies (for what they're worth) set over
>>> non-secure HTTP would be forgotten at the end of the browser session.
>>>
>>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>>>
>>> Link to standard: N/A
>>>
>>> Platform coverage: All platforms
>>>
>>> Estimated or target release: Firefox 49
>>>
>>> Preference behind which this will be implemented:
>>> network.cookie.lifetime.httpSessionOnly
>>>
>>> Do other browser engines implement this? No
>>>
>>> [1]
>>>
>>> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
>>>
>>> [2] http://www.alexa.com/topsites/category/Top/News
>>>
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>
> Jason
>



-- 

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

Re: Intent to ship: Directory picking and directory drag-and-drop

[google]

Am Mittwoch, 23. September 2015 02:33:52 UTC+2 schrieb Jonas Sicking:
> On Tue, Sep 22, 2015 at 11:16 PM, Eric Rescorla  wrote:
> >> The api has been extensively discussed with all browser vendors and has
> >> changed substantially in response to this
> >
> > Can you please point me to those changes and to the security analysis?
> 
> Security wasn't discussed much in these conversations, and the changes
> were all syntactical and didn't affect security. That's not to say
> that no one has cared about security or been unaware about the
> security implications, it's more due to the fact that any security
> aspects here are likely to influence the API or the normative spec
> text.
> 
> But yes, I agree that we should have the security team look at this feature.
> 
> / Jonas

Any updates on this? How is the status? Feature is not shipped even in version 
45 :(. Thanks.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: One Firefox repository to rule them all

[Andrew Halberstadt]

This is really cool!

Though I much prefer firefoxtree's namespace updating to keep track of
remote heads over using bookmarks. I want a label that will always point
to the last known head on the server, so e.g
`hg update central && hg commit -m "Foo"` should not move 'central'.
Using bookmarks to track the remote heads is also incompatible with my
bookbinder extension which I've come to rely quite heavily on. This
would be a personal blocker for me to make the switch.

Maybe firefoxtree could be adapted to work with this new repo as well.
Or maybe I could look into doing something with remotenames.

Andrew



On 14/04/16 08:22 PM, Gregory Szorc wrote:

I'm pleased to announce the immediate availability of some *experimental*
read-only Mercurial repositories containing the combined, useful history of
the various Firefox repositories, all in chronological order and stored in
a more efficient format that is faster to clone and pull from and results
in faster client operations.

The repositories can be found at https://hg.mozilla.org/experimental. The
repository you likely want to clone is
https://hg.mozilla.org/experimental/firefox-unified. A visualization
showing the chronological history of the repo can be seen at
https://hg.mozilla.org/experimental/firefox-unified/graph.

The primary goal of these repositories is to provide developers (and
eventually automation) with more efficient interaction with the Firefox
source repositories. There are several secondary and side-benefits,
including improving the scalability of Try and MozReview's repositories.

More documentation about these repos is available at [1]. tl;dr

* The repositories contain all the commits from the Firefox repositories
you use everyday (central, inbound, fx-team, aurora, beta, esr, etc).
* The repositories do not contain all the *_RELBRANCH branches (which
basically have no value to the average developer).
* Thes unified repositories are ~300MB *smaller* than mozilla-central
despite containing ~28,000 more commits. This was achieved through light
magic.
* Mercurial bookmarks are used to track the heads of the various Firefox
repos.
* The pushlog data is derived from the first known push of a changeset, so
it should match what's on e.g. central, inbound, etc.
* Sadly, git-cinnabar won't be able to talk to these repos just yet due to
git-cinnabar not supporting some modern Mercurial features. A GitHub issue
is on file at [2].

If you use the "firefoxtree" extension to manage a unified repository
today, you should consider switching to one of these new unified
repositories instead: it should be faster and easier to reason about.

The repositories have the "experimental" label attached so we can reserve
the right to make changes without people complaining too loudly about
backwards compatibility. (But I wouldn't worry too much about stability -
I'm committed to keeping these running and improving them.) The goal is to
flush out issues with these repositories then remove the "experimental"
label. After that, we can have automation start consuming these
repositories. After that, we can perhaps start thinking about consolidating
around a single, canonical repository, including pushing. But that's a
topic for another day.

I'm very anxious for feedback on these repositories. Please make noise in
dev-version-cont...@lists.mozilla.org, #vcs, the "Developer Services:
Mercurial: hg.mozilla.org" bug component, or in bug 1108729.

[1]
https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
[2] https://github.com/glandium/git-cinnabar/issues/64



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

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Tantek Çelik]

On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson  wrote:
> Thanks for all the feedbck. I anticipated this proposal might not be
> practical with real world sites, so it's better to halt it here. :) I should
> have framed this email as an RFC instead of an intent to ship.
>

Thanks Chris for bringing up this "modest proposal". I for one
definitely had the feeling of "I would flip this on and try it
immediately for myself."


However, As EKR pointed out, Kyle Huey's

> Why should we be the ones to take the web compat hit on this?

is the fundamentally biggest issue.


There were numerous other issues brought up as well about what makes
the user more/less secure, typing in / sending their password more
times etc. that are potentially more debatable.


I'd like to see (a) revised/refined proposal(s) that ask(s):


What steps can we take in this direction WITHOUT breaking web compat?


E.g. since one of the issues raised is that *every* time a user
enters/submits a password over HTTP (not secure), it opens them to
being sniffed etc., thus it's good to discourage the frequency.

Some STRAW PROPOSALS that I expect others here (and UX folks) to
easily improve on:

1. Warning (perhaps similar to the invalid red glow) on password
inputs in forms with HTTP "action"

2. Warning (similarly) on HTTP-auth password dialogs

Both with wording making it clear that *the site* is requesting this
"password in the clear", and perhaps a suggestion to especially use
different passwords for any such sites.


The intent being to educate users about the sites that are asking them
to take more risks, and encouraging at least incrementally better
password (creating/use) behaviors.


Chris Peterson  wrote:
>
> Focusing on third-party session cookies is an interesting idea.
> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks and
> CDNs to use HTTPS, allowing content sites to use HTTPS without mixed content
> problems. Much later, we could consider sessionizing even HTTPS third-party
> cookies.

This is an interesting refinement, and perhaps worthy of testing
behind a flag to see how much "breaks".


> I'll think about telemetry probes that could be added to better understand
> these scenarios. I'm surprised we don't have much telemetry about cookie
> usage. Monica Chew wrote [1] about a Mozilla study of cookies, but that was
> only 573 users back in 2013.
>
>
> chris
>
> [1] http://monica-at-mozilla.blogspot.com/2013/10/cookie-counting.html


More telemetry on these scenarios would help inform both proposals and
decisions regarding this.

For that matter, how much telemetry do we have on frequency of user
password submissions on HTML forms over HTTP, or insecure HTTP-auth?

Thanks,

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

Re: Intent to ship: Directory picking and directory drag-and-drop

[Andrea Marchesini]

I'm working on this. From an implementation point of view, we have almost
everything done and behind pref.
There are still some patches to review but it should not take too long.
The only missing piece is to change form submission but I should be able to
finish it for the next week.

More important is the security implications for the directory picker: bug
907707.

b


On Fri, Apr 15, 2016 at 5:31 AM,  wrote:

> Am Mittwoch, 23. September 2015 02:33:52 UTC+2 schrieb Jonas Sicking:
> > On Tue, Sep 22, 2015 at 11:16 PM, Eric Rescorla  wrote:
> > >> The api has been extensively discussed with all browser vendors and
> has
> > >> changed substantially in response to this
> > >
> > > Can you please point me to those changes and to the security analysis?
> >
> > Security wasn't discussed much in these conversations, and the changes
> > were all syntactical and didn't affect security. That's not to say
> > that no one has cared about security or been unaware about the
> > security implications, it's more due to the fact that any security
> > aspects here are likely to influence the API or the normative spec
> > text.
> >
> > But yes, I agree that we should have the security team look at this
> feature.
> >
> > / Jonas
>
> Any updates on this? How is the status? Feature is not shipped even in
> version 45 :(. Thanks.
> ___
> 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

PSA: Cancel your old Try pushes

[Ryan VanderMeulen]

I'm sure most of you have experienced the pain of long backlogs on Try
(Windows in particular). While we'd all love to have larger pools of test
machines (and our Ops people are actively working on improving that!), one
often-overlooked thing people can do to help with the backlog Right Now is
to cancel pending jobs on pushes they no longer need (i.e. newer push to
Try, broken patch, already pushed to inbound, etc).

Treeherder makes it easy to do this - just hit the little circle with an X
icon on the right hand side adjacent to the "XX% - Y in progress" text
along the top bar of the push. You will be prompted whether you really want
to cancel all jobs on the push. Just hit OK and you're done.

Killing off unnecessary jobs can have a significant impact on wait times
and backlog, so your consideration is greatly appreciated!

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

Re: PSA: Cancel your old Try pushes

[Tim Guan-tin Chien]

I wonder if there is any use cases to do multiple Try pushes of different
changesets but with the same bug number. Should we automatically cancel the
old ones when there is a new one?

On Fri, Apr 15, 2016 at 8:47 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:

> I'm sure most of you have experienced the pain of long backlogs on Try
> (Windows in particular). While we'd all love to have larger pools of test
> machines (and our Ops people are actively working on improving that!), one
> often-overlooked thing people can do to help with the backlog Right Now is
> to cancel pending jobs on pushes they no longer need (i.e. newer push to
> Try, broken patch, already pushed to inbound, etc).
>
> Treeherder makes it easy to do this - just hit the little circle with an X
> icon on the right hand side adjacent to the "XX% - Y in progress" text
> along the top bar of the push. You will be prompted whether you really want
> to cancel all jobs on the push. Just hit OK and you're done.
>
> Killing off unnecessary jobs can have a significant impact on wait times
> and backlog, so your consideration is greatly appreciated!
>
> Thanks,
> Ryan
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[James Graham]

On 15/04/16 18:09, Tim Guan-tin Chien wrote:

I wonder if there is any use cases to do multiple Try pushes of different
changesets but with the same bug number. Should we automatically cancel the
old ones when there is a new one?


Unfortunately there are legitimate uses for e.g. comparing the effects 
of two different changesets related to the same bug.


On the other hand, without thinking too hard about the implementation 
details (which I am inclined to believe would be more complex than you 
might expect due to missing APIs, auth, etc.), it seems like it might be 
possible to extend |mach try| to prompt to cancel old pushes for the 
same bug.


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

On using MozAfterPaint properly

[Mike Conley]

Hello dev-platform,

TL;DR: MozAfterPaint and nsIDOMWindowUtils has been given some extra stuff
to make it easier to be sure that something you care about has been
painted. This is good, at the very least, for Talos tests.

Full-details:

I've recently made a change to MozAfterPaint that some of you might find
interesting. This is particularly interesting for people who work on or
with Talos tests where those tests are measuring how long until something
is presented to the user.

Traditionally, MozAfterPaint has been used by Talos tests[1] to "stop a
stopwatch" that's been ticking since some action started. For example, for
the tpaint Talos test[2], the stopwatch is started, and a new window is
opened up. Once the content in the new window sees the MozAfterPaint event,
we assume the content has been displayed to the user, and we stop the
stopwatch.

Note that MozAfterPaint is fired after both paint _and_ composition, so it
truly does mean "presented to the user"[3].

Now that we live in an OMTC world, there are complications. Specifically,
there are opportunities for a MozAfterPaint handler to hear a MozAfterPaint
that it doesn't actually care about.

Let me give you an example.

Suppose I'm writing a talos test that is measuring how long it takes for
something to paint after I've clicked some node with id="target". Normally,
I'd set up my MozAfterPaint handler, start the stopwatch, fire a click
event at the target, and wait for the MozAfterPaint in order to stop the
stopwatch. The problem is that there's the possibility that a composite was
underway while I was running my Talos script. That means that after I've
set my MozAfterPaint handler, I might hear a MozAfterPaint event before
layout and graphics have had a chance to react to my click on the target
element.

The fact that this is all kind of non-deterministic makes it a bit worse.
Sometimes we'll see the result we want, and sometimes, we'll see very short
results from our stopwatch due to an earlier composite that was in progress
when we ran our script.

To combat this, I've added the following:

1) An unsigned long long property to nsIDOMWindowUtils giving the last
transaction id that was sent to the compositor
2) An unsigned long long property on the MozAfterPaint event exposing which
transaction id this MozAfterPaint is for

To go back to our example, this means that what I should do is, before
starting the stopwatch, I should figure out what the lastTransactionId was
for the window I'm in, and remember it. When my MozAfterPaint event handler
runs, I should ensure that the transactionId on the event is _greater_ than
the lastTransactionId I had recorded earlier. It might not be exactly 1
value above. We just know it'll be greater. If it's greater, then we _know_
that whatever action we took when clicking the target, if it should cause a
paint, should have been included in this composite.

So that's that. Gory details are in bug 1264409. I've also filed bug
1264798 to investigate adding the composite end time in the MozAfterPaint
event for greater accuracy.

-Mike

[1]: It's also periodically used by front-end code to defer some activity
until something has been presented to the user.
[2]: https://wiki.mozilla.org/Buildbot/Talos/Tests#tpaint
[3]: The fact that it's called MozAfterPaint is probably for historical
reasons. It should probably be renamed to MozAfterPresented or something.
Meh.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[Jonas Sicking]

We could also make the default behavior be to cancel old pushes. And
then enable push message syntax for opting in to not cancelling.

/ Jonas

On Fri, Apr 15, 2016 at 10:19 AM, James Graham  wrote:
> On 15/04/16 18:09, Tim Guan-tin Chien wrote:
>>
>> I wonder if there is any use cases to do multiple Try pushes of different
>> changesets but with the same bug number. Should we automatically cancel
>> the
>> old ones when there is a new one?
>
>
> Unfortunately there are legitimate uses for e.g. comparing the effects of
> two different changesets related to the same bug.
>
> On the other hand, without thinking too hard about the implementation
> details (which I am inclined to believe would be more complex than you might
> expect due to missing APIs, auth, etc.), it seems like it might be possible
> to extend |mach try| to prompt to cancel old pushes for the same bug.
>
>
> ___
> 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: PSA: Cancel your old Try pushes

[Jim Blandy]

On Fri, Apr 15, 2016 at 12:36 PM, Jonas Sicking  wrote:

> We could also make the default behavior be to cancel old pushes. And
> then enable push message syntax for opting in to not cancelling.
>
>
This could be very frustrating (and cause farm work to be wasted) if it
happened accidentally.

Perhaps it would be less error-prone to require an explicit choice of
overlapping or cancellation, and immediately reject pushes that haven't
chosen one or the other, for bugs that already have running try pushes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[Mike Connor]

If this is a serious problem, and I can easily believe that it is, have we
considered having a default behaviour of cancelling all unfinished Try jobs
running for a given user when they push again?  Based on how I've seen
people use Try over the years, I suspect a significant majority of pushes
are updated versions of previous pushes.

For cases where a developer needs to run multiple runs at once, we can add
an override in the trychooser syntax.  I think that's a corner case, and I
don't think it would be a major burden vs. the cost/benefit for everyone
else.

I think the treeherder path we wouldn't need to auto-cancel, but we would
prompt when the user adds jobs from the web interface.

-- Mike

On Fri, Apr 15, 2016 at 11:47 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:

> I'm sure most of you have experienced the pain of long backlogs on Try
> (Windows in particular). While we'd all love to have larger pools of test
> machines (and our Ops people are actively working on improving that!), one
> often-overlooked thing people can do to help with the backlog Right Now is
> to cancel pending jobs on pushes they no longer need (i.e. newer push to
> Try, broken patch, already pushed to inbound, etc).
>
> Treeherder makes it easy to do this - just hit the little circle with an X
> icon on the right hand side adjacent to the "XX% - Y in progress" text
> along the top bar of the push. You will be prompted whether you really want
> to cancel all jobs on the push. Just hit OK and you're done.
>
> Killing off unnecessary jobs can have a significant impact on wait times
> and backlog, so your consideration is greatly appreciated!
>
> Thanks,
> Ryan
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[Steve Fink]

See bug 593096. (Hah! I anticipated you guys by almost 700,000 bugs!) 
It's currently WONTFIX, but there's some relevant discussion in there.


On 04/15/2016 12:46 PM, Mike Connor wrote:

If this is a serious problem, and I can easily believe that it is, have we
considered having a default behaviour of cancelling all unfinished Try jobs
running for a given user when they push again?  Based on how I've seen
people use Try over the years, I suspect a significant majority of pushes
are updated versions of previous pushes.

For cases where a developer needs to run multiple runs at once, we can add
an override in the trychooser syntax.  I think that's a corner case, and I
don't think it would be a major burden vs. the cost/benefit for everyone
else.

I think the treeherder path we wouldn't need to auto-cancel, but we would
prompt when the user adds jobs from the web interface.

-- Mike

On Fri, Apr 15, 2016 at 11:47 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:


I'm sure most of you have experienced the pain of long backlogs on Try
(Windows in particular). While we'd all love to have larger pools of test
machines (and our Ops people are actively working on improving that!), one
often-overlooked thing people can do to help with the backlog Right Now is
to cancel pending jobs on pushes they no longer need (i.e. newer push to
Try, broken patch, already pushed to inbound, etc).

Treeherder makes it easy to do this - just hit the little circle with an X
icon on the right hand side adjacent to the "XX% - Y in progress" text
along the top bar of the push. You will be prompted whether you really want
to cancel all jobs on the push. Just hit OK and you're done.

Killing off unnecessary jobs can have a significant impact on wait times
and backlog, so your consideration is greatly appreciated!

Thanks,
Ryan

___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev



___
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: PSA: Cancel your old Try pushes

[Gijs Kruitbosch]

On 15/04/2016 20:46, Mike Connor wrote:

For cases where a developer needs to run multiple runs at once, we can add
an override in the trychooser syntax.  I think that's a corner case


It isn't when you do any kind of talos "need to fix / not regress perf" 
work.


I agree with Jim that we should either force the user to choose or 
"only" warn when duplicate-bug trypushes happen.


~ Gijs

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

Re: PSA: Cancel your old Try pushes

[Boris Zbarsky]

On 4/15/16 1:09 PM, Tim Guan-tin Chien wrote:

I wonder if there is any use cases to do multiple Try pushes of different
changesets but with the same bug number.


A significant fraction of my try pushes are like this, actually. 
Typically this happens when I do a try push of a multi-changeset queue 
for a bug, get some mysterious failures, then do several pushes of more 
and more of the queue in an attempt to narrow down which changeset is 
causing the failures.



Should we automatically cancel the old ones when there is a new one?


If we set this up, I would probably just add whatever the "do not 
cancel" override is to my try syntax for everything, to avoid the 
inevitable footguns.  Unless there were a way to uncancel.


-Boris

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

Re: One Firefox repository to rule them all

[Gregory Szorc]

On Thu, Apr 14, 2016 at 9:34 PM,  wrote:

> When will mozilla-central use generaldelta?
>

It's complicated. But https://hg.mozilla.org/experimental/mozilla-central-gd
exists now. It is ~400 MB smaller than mozilla-central. I also filed bug
1265075 to track advertising a generaldelta bundle via the CDN-based
cloning feature.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: One Firefox repository to rule them all

[Gregory Szorc]

On Thu, Apr 14, 2016 at 6:45 PM, Dave Townsend 
wrote:

> On Thu, Apr 14, 2016 at 5:22 PM, Gregory Szorc  wrote:
>
>> I'm pleased to announce the immediate availability of some *experimental*
>> read-only Mercurial repositories containing the combined, useful history of
>> the various Firefox repositories, all in chronological order and stored in
>> a more efficient format that is faster to clone and pull from and results
>> in faster client operations.
>>
>
> Does this mean that it contains the full history including CVS?
>

No. Adding a Mercurial repo with CVS history isn't on the priority list.
Make a case for it improving developer productivity and it could be.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: One Firefox repository to rule them all

[Kris Maglione]

On Fri, Apr 15, 2016 at 01:29:10PM -0700, Gregory Szorc wrote:

On Thu, Apr 14, 2016 at 6:45 PM, Dave Townsend 
wrote:

Does this mean that it contains the full history including CVS?


No. Adding a Mercurial repo with CVS history isn't on the priority list.
Make a case for it improving developer productivity and it could be.


I often start looking at the blame history in a file I'm working 
in, run into a dead end at the initial CVS import, and then have 
to switch to gecko-dev to find what I'm looking for.


That's not great when I'm working locally, and happen to have 
up-to-date copies of both repos. But when I'm looking at blame 
data that I got to from DXR, and then have to switch to Github, 
find the file again, search through the history, and then 
eventually give up and check out a copy of gecko-dev so I can 
check locally, it's a major waste of time and energy.

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

Re: PSA: Cancel your old Try pushes

[Kartikaya Gupta]

I also often have multiple pushes going at the same time. My
suggestion to solve this problem is: have a cron job that detects
users who have more than N pushes with jobs still going, and send them
an email saying "you have a lot of jobs going, here's the list; you
might find something you should cancel in there".

Personally, I do keep an eye on my pushes and try to cancel stuff as
it becomes unnecessary, but sometimes there might be a few pending
jobs on very old pushes that I've neglected to cancel, and will likely
not push with that bug number anymore. An email reminder that lists
those old pushes would make me realize I can cancel them.

kats


On Fri, Apr 15, 2016 at 4:02 PM, Boris Zbarsky  wrote:
> On 4/15/16 1:09 PM, Tim Guan-tin Chien wrote:
>>
>> I wonder if there is any use cases to do multiple Try pushes of different
>> changesets but with the same bug number.
>
>
> A significant fraction of my try pushes are like this, actually. Typically
> this happens when I do a try push of a multi-changeset queue for a bug, get
> some mysterious failures, then do several pushes of more and more of the
> queue in an attempt to narrow down which changeset is causing the failures.
>
>> Should we automatically cancel the old ones when there is a new one?
>
>
> If we set this up, I would probably just add whatever the "do not cancel"
> override is to my try syntax for everything, to avoid the inevitable
> footguns.  Unless there were a way to uncancel.
>
> -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: One Firefox repository to rule them all

[Gregory Szorc]

On Fri, Apr 15, 2016 at 7:16 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:

> This is really cool!
>
> Though I much prefer firefoxtree's namespace updating to keep track of
> remote heads over using bookmarks. I want a label that will always point
> to the last known head on the server, so e.g
> `hg update central && hg commit -m "Foo"` should not move 'central'.
> Using bookmarks to track the remote heads is also incompatible with my
> bookbinder extension which I've come to rely quite heavily on. This
> would be a personal blocker for me to make the switch.
>
> Maybe firefoxtree could be adapted to work with this new repo as well.
> Or maybe I could look into doing something with remotenames.
>

There is actually a mode in firefoxtree where the server can advertise the
labels. We're not using it on the unified repo yet, but we could. Let's
hash something out in bug 1264814.


>
>
>
>
> On 14/04/16 08:22 PM, Gregory Szorc wrote:
>
>> I'm pleased to announce the immediate availability of some *experimental*
>> read-only Mercurial repositories containing the combined, useful history
>> of
>> the various Firefox repositories, all in chronological order and stored in
>> a more efficient format that is faster to clone and pull from and results
>> in faster client operations.
>>
>> The repositories can be found at https://hg.mozilla.org/experimental. The
>> repository you likely want to clone is
>> https://hg.mozilla.org/experimental/firefox-unified. A visualization
>> showing the chronological history of the repo can be seen at
>> https://hg.mozilla.org/experimental/firefox-unified/graph.
>>
>> The primary goal of these repositories is to provide developers (and
>> eventually automation) with more efficient interaction with the Firefox
>> source repositories. There are several secondary and side-benefits,
>> including improving the scalability of Try and MozReview's repositories.
>>
>> More documentation about these repos is available at [1]. tl;dr
>>
>> * The repositories contain all the commits from the Firefox repositories
>> you use everyday (central, inbound, fx-team, aurora, beta, esr, etc).
>> * The repositories do not contain all the *_RELBRANCH branches (which
>> basically have no value to the average developer).
>> * Thes unified repositories are ~300MB *smaller* than mozilla-central
>> despite containing ~28,000 more commits. This was achieved through light
>> magic.
>> * Mercurial bookmarks are used to track the heads of the various Firefox
>> repos.
>> * The pushlog data is derived from the first known push of a changeset, so
>> it should match what's on e.g. central, inbound, etc.
>> * Sadly, git-cinnabar won't be able to talk to these repos just yet due to
>> git-cinnabar not supporting some modern Mercurial features. A GitHub issue
>> is on file at [2].
>>
>> If you use the "firefoxtree" extension to manage a unified repository
>> today, you should consider switching to one of these new unified
>> repositories instead: it should be faster and easier to reason about.
>>
>> The repositories have the "experimental" label attached so we can reserve
>> the right to make changes without people complaining too loudly about
>> backwards compatibility. (But I wouldn't worry too much about stability -
>> I'm committed to keeping these running and improving them.) The goal is to
>> flush out issues with these repositories then remove the "experimental"
>> label. After that, we can have automation start consuming these
>> repositories. After that, we can perhaps start thinking about
>> consolidating
>> around a single, canonical repository, including pushing. But that's a
>> topic for another day.
>>
>> I'm very anxious for feedback on these repositories. Please make noise in
>> dev-version-cont...@lists.mozilla.org, #vcs, the "Developer Services:
>> Mercurial: hg.mozilla.org" bug component, or in bug 1108729.
>>
>> [1]
>>
>> https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
>> [2] https://github.com/glandium/git-cinnabar/issues/64
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposed W3C Charter: Timed Text Working Group

[L. David Baron]

The W3C is proposing a charter for:

  Timed Text Working Group
  http://w3c.github.io/charter-drafts/timed-text-charter-2016.html
  https://lists.w3.org/Archives/Public/public-new-work/2016Apr/0010.html

  The diff between this charter and the group's previous charter is:
  
http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%2F03%2Ftimed-text-charter.html&doc2=http%3A%2F%2Fw3c.github.io%2Fcharter-drafts%2Ftimed-text-charter-2016.html

Mozilla has the opportunity to send comments or objections through
Friday, May 13.

Please reply to this thread if you think there's something we should
say as part of this charter review.

-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)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[Brian Grinstead]

> On Apr 15, 2016, at 12:44 PM, Jim Blandy  wrote:
> 
> On Fri, Apr 15, 2016 at 12:36 PM, Jonas Sicking  wrote:
> 
>> We could also make the default behavior be to cancel old pushes. And
>> then enable push message syntax for opting in to not cancelling.
>> 
>> 
> This could be very frustrating (and cause farm work to be wasted) if it
> happened accidentally.
> 
> Perhaps it would be less error-prone to require an explicit choice of
> overlapping or cancellation, and immediately reject pushes that haven't
> chosen one or the other, for bugs that already have running try pushes.

Explicit choice sounds good.  I'd rather it not be required before pushing if 
it were a prompt.  If it were a try syntax option I would likely set "do not 
cancel" as a default to prevent accidental cancellation.

My proposal: enhance mach try to surface this information and allow convenient 
cancellation.  And if it were pushed using some other manner like a web ui or 
hg push then the default behavior would remain as it is today (to prevent 
losing work by default).  So something like this:

   $ ./mach try args

   remote: adding changesets
   remote: adding manifests
   remote: adding file changes
   remote: added 2 changesets with 1 changes to 2 files (+1 heads)
   remote: recorded push in pushlog
   remote:
   remote: View your changes here:
   remote:   https://hg.mozilla.org/try/rev/REV1
   remote:   https://hg.mozilla.org/try/rev/REV2
   remote:
   remote: Follow the progress of your build on Treeherder:
   remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=REV2
   remote: recorded changegroup in replication log in 0.093s

   Please help make Try faster by canceling old jobs.  You have two existing 
builds for this bug:

 https://treeherder.mozilla.org/#/jobs?repo=try&revision=REV3 (50% complete)
 https://treeherder.mozilla.org/#/jobs?repo=try&revision=REV4 (90% complete)

   Would you like to cancel these jobs? (Y/N)

Brian

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

Proposed W3C Charter: Browser Testing and Tools WG

[L. David Baron]

[ also bcc:ed David Burns, who's the proposed chair of the group ]

The W3C is proposing a charter for:

  Browser Testing and Tools Working Group
  http://w3c.github.io/charter-drafts/browser-testing-tools.html
  https://lists.w3.org/Archives/Public/public-new-work/2016Apr/0006.html

Mozilla has the opportunity to send comments or objections through
Sunday, May 3.

Please reply to this thread if you think there's something we should
say as part of this charter review.

-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)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Matthew N.]

On 2016-04-15 7:47 AM, Tantek Çelik wrote:

What steps can we take in this direction WITHOUT breaking web compat?


E.g. since one of the issues raised is that *every* time a user
enters/submits a password over HTTP (not secure), it opens them to
being sniffed etc., thus it's good to discourage the frequency.

Some STRAW PROPOSALS that I expect others here (and UX folks) to
easily improve on:

1. Warning (perhaps similar to the invalid red glow) on password
inputs in forms with HTTP "action"


We are making progress towards this and Aislinn Grigas from UX worked on 
a design for something like this: 
https://bugzilla.mozilla.org/attachment.cgi?id=8678150


We already started developer-specific warnings in the web console and in 
the address bar of Nightly + Developer Edition: 
https://hacks.mozilla.org/2016/01/login-forms-over-https-please/


There are some dependencies to fix before doing user-facing warnings 
which we're currently working on. You can follow along in the bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1217162



2. Warning (similarly) on HTTP-auth password dialogs


This is https://bugzilla.mozilla.org/show_bug.cgi?id=1185145 which I 
haven't seen a design for yet but should be less risky to implement than 
for . It is in the Firefox privacy/security team backlog.


Meta bug related to dealing with insecure login forms: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1217142


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

Re: Proposed W3C Charter: Timed Text Working Group

[Ralph Giles]

I'm not sure there's much to say here. I think we should remain
uninterested in the TTML efforts. Work to define translation from
CEA608 and CEA708 to WebVTT is worthwhile, and I'd like to see it
supported. Unfortunately our interest in WebVTT has been mostly
theoretical recently, so I don't see us contributing to it.

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

Re: Dump frame tree in real time

[Botond Ballo]

On Fri, Apr 15, 2016 at 4:32 AM, Jip de Beer  wrote:
> Thanks for the reply. My problem with display lists is that they only contain 
> this information about nodes within the viewport. I'm interested in all nodes 
> that take up space within the document.
>
> I know Firefox can calculate the necessary information for nodes outside of 
> the viewport because I can take a screenshot of the entire page with 
> CanvasRenderingContext2D.drawWindow() and it correctly renders the entire 
> page (also outside of the viewport).

If it renders the entire page, it must build a display list for the
entire page. Can you get a display list dump from that operation?

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

Re: PSA: Cancel your old Try pushes

[Xidorn Quan]

On Sat, Apr 16, 2016 at 1:47 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:

> I'm sure most of you have experienced the pain of long backlogs on Try
> (Windows in particular). While we'd all love to have larger pools of test
> machines (and our Ops people are actively working on improving that!), one
> often-overlooked thing people can do to help with the backlog Right Now is
> to cancel pending jobs on pushes they no longer need (i.e. newer push to
> Try, broken patch, already pushed to inbound, etc).
>
> Treeherder makes it easy to do this - just hit the little circle with an X
> icon on the right hand side adjacent to the "XX% - Y in progress" text
> along the top bar of the push. You will be prompted whether you really want
> to cancel all jobs on the push. Just hit OK and you're done.
>
> Killing off unnecessary jobs can have a significant impact on wait times
> and backlog, so your consideration is greatly appreciated!
>

Can we probably provide an additional banner on the top of the treeherder
which shows all try pushes one has pushed in progress? I suppose it would
make people easier to find and switch between their own try pushes, and
also make it more convenient to cancel old pushes they no longer need
without adding much annoyance.

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

Re: PSA: Cancel your old Try pushes

[Steve Fink]

On 04/15/2016 05:11 PM, Xidorn Quan wrote:

On Sat, Apr 16, 2016 at 1:47 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:


I'm sure most of you have experienced the pain of long backlogs on Try
(Windows in particular). While we'd all love to have larger pools of test
machines (and our Ops people are actively working on improving that!), one
often-overlooked thing people can do to help with the backlog Right Now is
to cancel pending jobs on pushes they no longer need (i.e. newer push to
Try, broken patch, already pushed to inbound, etc).

Treeherder makes it easy to do this - just hit the little circle with an X
icon on the right hand side adjacent to the "XX% - Y in progress" text
along the top bar of the push. You will be prompted whether you really want
to cancel all jobs on the push. Just hit OK and you're done.

Killing off unnecessary jobs can have a significant impact on wait times
and backlog, so your consideration is greatly appreciated!


Can we probably provide an additional banner on the top of the treeherder
which shows all try pushes one has pushed in progress? I suppose it would
make people easier to find and switch between their own try pushes, and
also make it more convenient to cancel old pushes they no longer need
without adding much annoyance.
Doesn't everyone keep a tab open to their try page? eg I have 
https://treeherder.mozilla.org/#/jobs?repo=try&author=sf...@mozilla.com 
open all the time. I used to use the try emails to find my previous 
pushes, which was a PITA. But that page is really very nice, and 
provides an easy way to cancel pushes too.


Though I'd kind of like to be able to click on something to remove one 
of those from the view, to make it easier to keep track of what's still 
relevant to me.



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

Re: PSA: Cancel your old Try pushes

[Xidorn Quan]

On Sat, Apr 16, 2016 at 10:24 AM, Steve Fink  wrote:

> On 04/15/2016 05:11 PM, Xidorn Quan wrote:
>
>> On Sat, Apr 16, 2016 at 1:47 AM, Ryan VanderMeulen <
>> rvandermeu...@mozilla.com> wrote:
>>
>> I'm sure most of you have experienced the pain of long backlogs on Try
>>> (Windows in particular). While we'd all love to have larger pools of test
>>> machines (and our Ops people are actively working on improving that!),
>>> one
>>> often-overlooked thing people can do to help with the backlog Right Now
>>> is
>>> to cancel pending jobs on pushes they no longer need (i.e. newer push to
>>> Try, broken patch, already pushed to inbound, etc).
>>>
>>> Treeherder makes it easy to do this - just hit the little circle with an
>>> X
>>> icon on the right hand side adjacent to the "XX% - Y in progress" text
>>> along the top bar of the push. You will be prompted whether you really
>>> want
>>> to cancel all jobs on the push. Just hit OK and you're done.
>>>
>>> Killing off unnecessary jobs can have a significant impact on wait times
>>> and backlog, so your consideration is greatly appreciated!
>>>
>>> Can we probably provide an additional banner on the top of the treeherder
>> which shows all try pushes one has pushed in progress? I suppose it would
>> make people easier to find and switch between their own try pushes, and
>> also make it more convenient to cancel old pushes they no longer need
>> without adding much annoyance.
>>
> Doesn't everyone keep a tab open to their try page? eg I have
> https://treeherder.mozilla.org/#/jobs?repo=try&author=sf...@mozilla.com
> open all the time. I used to use the try emails to find my previous pushes,
> which was a PITA. But that page is really very nice, and provides an easy
> way to cancel pushes too.
>

No, I don't. I open separate pages for each try push, and put them under in
the subtree of the tab of their corresponding bug.

A page showing all data of all my try pushes could be too long to be
useful. I think a brief information of in-progress pushes which serves as a
light warning would be the best.

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

Re: PSA: Cancel your old Try pushes

[KWierso]

On Friday, April 15, 2016 at 5:11:55 PM UTC-7, Xidorn Quan wrote:
> On Sat, Apr 16, 2016 at 1:47 AM, Ryan VanderMeulen <
> rvandermeu...@mozilla.com> wrote:
> 
> > I'm sure most of you have experienced the pain of long backlogs on Try
> > (Windows in particular). While we'd all love to have larger pools of test
> > machines (and our Ops people are actively working on improving that!), one
> > often-overlooked thing people can do to help with the backlog Right Now is
> > to cancel pending jobs on pushes they no longer need (i.e. newer push to
> > Try, broken patch, already pushed to inbound, etc).
> >
> > Treeherder makes it easy to do this - just hit the little circle with an X
> > icon on the right hand side adjacent to the "XX% - Y in progress" text
> > along the top bar of the push. You will be prompted whether you really want
> > to cancel all jobs on the push. Just hit OK and you're done.
> >
> > Killing off unnecessary jobs can have a significant impact on wait times
> > and backlog, so your consideration is greatly appreciated!
> >
> 
> Can we probably provide an additional banner on the top of the treeherder
> which shows all try pushes one has pushed in progress? I suppose it would
> make people easier to find and switch between their own try pushes, and
> also make it more convenient to cancel old pushes they no longer need
> without adding much annoyance.
> 
> - Xidorn

There's a Treeherder bug on file for providing a view like that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: One Firefox repository to rule them all

[smaug]

On 04/15/2016 11:29 PM, Gregory Szorc wrote:

On Thu, Apr 14, 2016 at 6:45 PM, Dave Townsend 
wrote:


On Thu, Apr 14, 2016 at 5:22 PM, Gregory Szorc  wrote:


I'm pleased to announce the immediate availability of some *experimental*
read-only Mercurial repositories containing the combined, useful history of
the various Firefox repositories, all in chronological order and stored in
a more efficient format that is faster to clone and pull from and results
in faster client operations.



Does this mean that it contains the full history including CVS?



No. Adding a Mercurial repo with CVS history isn't on the priority list.
Make a case for it improving developer productivity and it could be.



Spending occasionally tons of times trying to find relevant code in viewvc
(which usability is far from bonsai and even worse than hg blame).
Is wasted developer time not a good enough case?
Also, not having CVS history easily available reduces the quality of the 
reviews since at least I too easily
give up looking at the blame if the blame is in CVS.

Using gecko-dev is not an option since Github's blame chokes on any large files 
(which happen to contain
most the interesting stuff).


However, thanks a ton for having http://52.25.115.98/viewvc/main/ !
That is better than nothing.



-Olli

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

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

On 4/15/16 7:47 AM, Tantek Çelik wrote:

What steps can we take in this direction WITHOUT breaking web compat?


Would this feature actually break web compatibility? Or just needlessly 
annoy users?


In his original post, Henri argued that clearing non-HTTPS cookies 
between sessions would not "Break the Web". There would be no user- or 
site-detectable changes mid-session. Clearing cookies between sessions 
could be user-detectable if they get logged out or lose their shopping 
cart. Sites, OTOH, must already handle the cases were a user's cookies 
are lost between sessions. Users could clear their cookies, use Private 
Browsing mode, or log into the site from a different browser or device.



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

Re: One Firefox repository to rule them all

[Nicholas Nethercote]

For me, having the CVS history in the mozilla-central repo would be
much more helpful than having all the different repositories in one.

Nick

On Sat, Apr 16, 2016 at 11:41 AM, smaug  wrote:
> On 04/15/2016 11:29 PM, Gregory Szorc wrote:
>>
>> On Thu, Apr 14, 2016 at 6:45 PM, Dave Townsend 
>> wrote:
>>
>>> On Thu, Apr 14, 2016 at 5:22 PM, Gregory Szorc  wrote:
>>>
 I'm pleased to announce the immediate availability of some
 *experimental*
 read-only Mercurial repositories containing the combined, useful history
 of
 the various Firefox repositories, all in chronological order and stored
 in
 a more efficient format that is faster to clone and pull from and
 results
 in faster client operations.

>>>
>>> Does this mean that it contains the full history including CVS?
>>>
>>
>> No. Adding a Mercurial repo with CVS history isn't on the priority list.
>> Make a case for it improving developer productivity and it could be.
>>
>
> Spending occasionally tons of times trying to find relevant code in viewvc
> (which usability is far from bonsai and even worse than hg blame).
> Is wasted developer time not a good enough case?
> Also, not having CVS history easily available reduces the quality of the
> reviews since at least I too easily
> give up looking at the blame if the blame is in CVS.
>
> Using gecko-dev is not an option since Github's blame chokes on any large
> files (which happen to contain
> most the interesting stuff).
>
>
> However, thanks a ton for having http://52.25.115.98/viewvc/main/ !
> That is better than nothing.
>
>
>
> -Olli
>
>
> ___
> 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