Re: [dev-servo] 25% Improvement in page load time!

[Shing Lyu]

Done! https://github.com/servo/servo/issues/11888

Thanks for the suggestion.

Best,
Shing

 - Shing Lyu | Mozilla Taipei

2016-06-28 3:56 GMT+08:00 Jet Villegas :

> I see that Servo was replacing an iterating strcmp with hashing, so that
> explains the speed wins they're seeing. Maybe they should look into bsearch
> for the memory wins too, if speed is comparable.
>
> Shing Lyu: will you note that in the Servo github issue?
>
> Thanks,
>
> --Jet
>
>
> On Mon, Jun 27, 2016 at 11:15 AM, Nathan Froyd  wrote:
>
>> On Mon, Jun 27, 2016 at 2:01 PM, Jet Villegas 
>> wrote:
>> > Shing Lyu from our Taipei Layout team reports a 25% page load
>> improvement
>> > in Servo from moving to a hashtable lookup from an iterator search of
>> the
>> > public suffix list ( https://publicsuffix.org/ )
>> >
>> > Should Gecko do the same thing and replace our binary search method?
>> >
>> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSiteSecurityService.cpp#917
>>
>> Gecko's public suffix code lives over in netwerk/dns/:
>>
>>
>> https://hg.mozilla.org/mozilla-central/file/tip/netwerk/dns/nsEffectiveTLDService.cpp#l51
>>
>> Bug 1247835 [1] changed its hashtable usage to a binary search earlier
>> this year and we have not noticed any negative fallout.  Performance
>> measurements in the bug suggest the binary search might actually be
>> slightly faster, and the current structure enables us to easily share
>> the lookup structures between processes, as well as being smaller than
>> the previous hashtable scheme.  (If we switched to downloading public
>> suffix lists--bug 1083971 [2]--the sharing would presumably go away,
>> but we'd still get the size wins.)
>>
>> -Nathan
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1247835
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1083971
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: unprefixed unicode-bidi values

[Xidorn Quan]

Summary:
Some values of unicode-bidi (isolate, isolate-override, plaintext) have
been implemented with -moz- prefix for quite a while. And now I have a
build which passes all tests of this property from CSS working group, so I
think it is good time to unprefix.

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

Link to standard: https://drafts.csswg.org/css-writing-modes-3/#unicode-bidi

Platform coverage: all platforms

Estimated or target release: Firefox 50

Do other browser engines implement this?
Chrome has shipped unprefixed unicode-bidi values since 48 when they passed
all tests of that property.

Preference behind which this will be implemented: n/a
DevTools bug: n/a
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Rewritten `mach mercurial-setup` / Mercurial slides from London

[Gregory Szorc]

As of a few weeks ago, `mach mercurial-setup` and its integration with mach
have been rewritten.

The Mercurial configuration wizard has been rewritten and contains a number
of new features. If you haven't executed `mach mercurial-setup` lately, I
encourage you to do so to ensure you have the latest goodness.

Many of you will be happy that the requirement to run `mach
mercurial-setup` the first time you run `mach` from a Mercurial checkout
has been removed. This is because `mach bootstrap` and the standalone
bootstrap.py tool we recommend to new contributors now a) prompts you to
run the Mercurial config wizard b) clone the Mercurial repository. Since
the bootstrap tool increases the visibility of the Mercurial config wizard,
we no longer need to aggressively advertise it when running `mach`.

I'd like to thank glob and glandium for help with the code reviews.

While I'm here, there was a "Mercurial Workflows" session in London. The
slides are available at https://people.mozilla.org/~gszorc/hg-workflows/.
___
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 Mon, Jun 27, 2016 at 3:36 PM, Mike Hommey  wrote:

> On Mon, Jun 27, 2016 at 02:23:52PM -0700, Gregory Szorc wrote:
> > The unified Firefox repo has now been moved out of experimental status
> and
> > is available at https://hg.mozilla.org/mozilla-unified
> > .
>
> Which one is it? firefox/ or mozilla-unified/? Both exist and don't seem
> to contain the same things.
>
> > (Note: https://hg.mozilla.org/firefox was the initial planned location
> for
> > the unified repo and some of you may have started using it. There was a
> > last minute change of name to "mozilla-unified."
> > https://hg.mozilla.org/firefox is no longer updating and will
> eventually be
> > deleted.)
>
> Okay, so here's the answer, but why mention both?


This was my email client (gmail web) not changing the link when I changed
the URL text of the draft message I composed 2 weeks ago :/

And the bundle issue is known. mozilla-unified will use the bundles for the
"firefox" repo for another few hours until the bundles are regenerated.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Tanvi Vyas]

Is it possible to safely redirect mxr to dxr?

When I use my awesomebar and type "docshell", it pulls up 
https://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp. 
I click enter and end up at the mxr error page.  So instead I do a dxr 
search for docshell and scroll through a list of results, none of which 
seem to give me a link to nsDocShell.cpp.  It would be great if the mxr 
link sent me directly to 
https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp.


Alternatively, I could create an addon that does this or try and write a 
script that would change my history entries.


Thanks!

~Tanvi

On 6/22/16 11:30 AM, Lawrence Mandel wrote:


Mozilla Cross-Reference, better known as MXR 
(https://mxr.mozilla.org), was taken offline on June 13, 2016, to 
investigate a potential security issue. After careful review of the 
codebase, we have decided to accelerate the planned transition from 
MXR to its more modern equivalent, DXR (https://dxr.mozilla.org), 
instead of bringing MXR back online. As far as we know there was never 
a security compromise, but the unsupported legacy codebase (forked 
from an old version of LXR) would require significant time and effort 
to rewrite and bring up to spec.



Our transition plan is as follows:


 *

Add an interstitial web page at https://mxr.mozilla.orgthat
displays a best-guess URL for the equivalent
https://dxr.mozilla.orgfile data. This will help interactive users
retrieve data from historical links in applications like Bugzilla.

 *

Redirect certdata.txt and effective_tld_names.dat to their
canonical source code repositories instead of DXR. All other
search queries and automatic pulling of raw files by third parties
will no longer be supported at the https://mxr.mozilla.orgURL.

 *

Index the remaining repos listed in MXR in DXR for data parity,
using bug 1281443 to track progress. Repos will be indexed in the
order listed unless otherwise specified. If you need to prioritize
the indexing of specific repos, please open a bug and block
against bug 1281443.


Our expectation is that the interstitial page will be in place and the 
following remaining high-priority repos will be indexed by June 24th, 
2016:


 *

add-ons

 *

servo

 *

l10n


If you have concerns, questions, or requests, please open a new bug 
and mark it as blocking bug 1281443 or add a comment to one of its 
existing dependent bugs. Additional status updates will also be posted 
to bug 1281443 and its dependent bugs.



Lawrence



___
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: One Firefox repository to rule them all

[Mike Hommey]

On Tue, Jun 28, 2016 at 07:36:52AM +0900, Mike Hommey wrote:
> On Mon, Jun 27, 2016 at 02:23:52PM -0700, Gregory Szorc wrote:
> > The unified Firefox repo has now been moved out of experimental status and
> > is available at https://hg.mozilla.org/mozilla-unified
> > .
> 
> Which one is it? firefox/ or mozilla-unified/? Both exist and don't seem
> to contain the same things.

BTW, firefox/ has bundles on hg.cdn.mozilla.net, but mozilla-unified/ doesn't.

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

Re: One Firefox repository to rule them all

[Mike Hommey]

On Mon, Jun 27, 2016 at 02:23:52PM -0700, Gregory Szorc wrote:
> The unified Firefox repo has now been moved out of experimental status and
> is available at https://hg.mozilla.org/mozilla-unified
> .

Which one is it? firefox/ or mozilla-unified/? Both exist and don't seem
to contain the same things.

> (Note: https://hg.mozilla.org/firefox was the initial planned location for
> the unified repo and some of you may have started using it. There was a
> last minute change of name to "mozilla-unified."
> https://hg.mozilla.org/firefox is no longer updating and will eventually be
> deleted.)

Okay, so here's the answer, but why mention both?

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

Re: [Go Faster] WebCompat Go Faster Add-on

[Mike Taylor]

On 6/27/16 3:20 PM, Justin Dolske wrote:

I'm asking because this is code shipping to end-users, so I'd expect it
to adhere to basically the same engineering standards as code that ships
as part of baseline Firefox. AFAIK this is the first time that's really
been a question -- our other system addons (Hello, Pocket) started off
in Firefox, and just changed their delivery vehicle.

To be more specific:

* Who are the people that will be reviewing code that ships in this
addon? I don't see anything in the docs about code review or who can do
it. Will there be a module? Would the relevant platform reviewers be
used when shimming in DOM APIs?


I don't know how the module system works wrt go faster add-ons. But 
maybe someone can add some clarity around this this.


I'd likely be reviewing patches written against sites, within our team. 
And we'd be asking people with more Firefox/XPCOM/go faster experience 
to review the site patching infrastructure. We'd absolutely be asking 
for review from DOM peers if and when we shim any APIs. If someone wants 
to step up and volunteer to review all our patches, that's also great.



* The docs do expand a bit on testing, but it sounds like a one-time QA
signoff. That's an important part, but I don't see anything about
automated / ongoing tests (against product code or website code). For
example, if a Gecko change breaks something the addon is relying on,
when will that be noticed? Or if the addon's patch for a site stops
working (or, worse, breaks it!) due to a change the site deploys after
the addon is released, when will that be noticed?


I sort of expanded on that in my reply to Benjamin. Right now it's a 
very hand-wavey TODO item here: 



We don't plan on shipping site patches without this kind of ongoing 
sites -- sites change all the time, and often developers fix bugs 
without letting us know (once we're at the outreach stage).



* Similarly to correctness testing, how is performance testing dealt with?


For this go faster add-on, or go faster add-ons in general?

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Go Faster] WebCompat Go Faster Add-on

[Mike Taylor]

On Mon, Jun 27, 2016 at 2:26 PM, Cory Price > wrote:


On Mon, Jun 27, 2016 at 11:05 AM, Justin Dolske > wrote:

What's the policy for reviews and testing with this addon?


You can see the current process for deploying things in the Go
Faster documentation (Wiki
, Release Process

).


Thanks, I wasn't aware of the Release Process doc (so I guess I owe an 
"Intent to Implement" email to the right lists in the coming weeks).


On 6/27/16 1:45 PM, Benjamin Smedberg wrote:
>

This seems like an inadequate answer to the particular question: who in
particular is the module owner of this code, who is responsible for
doing code review?


How do other go faster addons operate? My naive answer is people on our 
team.


> And who is the QA/QE lead for this addon and what
> kind of systems will be used to determine whether a particular webcompat
> tweak is working both before before and after deployment?

If you read the explainer doc, near the end we mention needing automated 
testing to verify that patches are needed post-deployment. We've built 
similar things in the past for testing "bugfix" regressions. The design 
of that is TBD, but our team will build it and monitor it.


One of the requirements of this addon is that it can be (temporarily) 
disabled so site owners can verify that they've fixed things. We don't 
have dedicated QA resources, so this will likely be a manual process by 
our team: turn it off, verify, turn it on, verify, etc.


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Go Faster] WebCompat Go Faster Add-on

[Justin Dolske]

I'm not really clear what part of those docs covers my questions. Either
I'm missing it, or my question wasn't clear...

I'm asking because this is code shipping to end-users, so I'd expect it to
adhere to basically the same engineering standards as code that ships as
part of baseline Firefox. AFAIK this is the first time that's really been a
question -- our other system addons (Hello, Pocket) started off in Firefox,
and just changed their delivery vehicle.

To be more specific:

* Who are the people that will be reviewing code that ships in this addon?
I don't see anything in the docs about code review or who can do it. Will
there be a module? Would the relevant platform reviewers be used when
shimming in DOM APIs?

* The docs do expand a bit on testing, but it sounds like a one-time QA
signoff. That's an important part, but I don't see anything about automated
/ ongoing tests (against product code or website code). For example, if a
Gecko change breaks something the addon is relying on, when will that be
noticed? Or if the addon's patch for a site stops working (or, worse,
breaks it!) due to a change the site deploys after the addon is released,
when will that be noticed?

* Similarly to correctness testing, how is performance testing dealt with?

Justin

On Mon, Jun 27, 2016 at 12:09 PM, Cory Price  wrote:

> The answer was focused on the policy question which should be covered for
> the most part in the documentation. With respect to individual roles and
> responsibilities for this add-on, I've added it to the agenda in the
> aforementioned team check-in.
>
> On Mon, Jun 27, 2016 at 11:45 AM, Benjamin Smedberg  > wrote:
>
>>
>> On Mon, Jun 27, 2016 at 2:26 PM, Cory Price  wrote:
>>
>>>
>>> On Mon, Jun 27, 2016 at 11:05 AM, Justin Dolske 
>>> wrote:
>>>
 What's the policy for reviews and testing with this addon?

>>>
>>> You can see the current process for deploying things in the Go Faster
>>> documentation (Wiki , Release
>>> Process
>>> 
>>> ).
>>>
>>> I've also added this to our system add-on pipeline
>>>  which
>>> we discuss in our weekly meetings (invited Mike/Justin).
>>>
>>
>> This seems like an inadequate answer to the particular question: who in
>> particular is the module owner of this code, who is responsible for doing
>> code review? And who is the QA/QE lead for this addon and what kind of
>> systems will be used to determine whether a particular webcompat tweak is
>> working both before before and after deployment?
>>
>> --BDS
>>
>> --
>> Benjamin Smedberg
>> Engineering Manager, Firefox
>>
>>
>
>
> --
> Cory Price
> /ckprice
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [dev-servo] 25% Improvement in page load time!

[Jet Villegas]

I see that Servo was replacing an iterating strcmp with hashing, so that
explains the speed wins they're seeing. Maybe they should look into bsearch
for the memory wins too, if speed is comparable.

Shing Lyu: will you note that in the Servo github issue?

Thanks,

--Jet


On Mon, Jun 27, 2016 at 11:15 AM, Nathan Froyd  wrote:

> On Mon, Jun 27, 2016 at 2:01 PM, Jet Villegas 
> wrote:
> > Shing Lyu from our Taipei Layout team reports a 25% page load improvement
> > in Servo from moving to a hashtable lookup from an iterator search of the
> > public suffix list ( https://publicsuffix.org/ )
> >
> > Should Gecko do the same thing and replace our binary search method?
> >
> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSiteSecurityService.cpp#917
>
> Gecko's public suffix code lives over in netwerk/dns/:
>
>
> https://hg.mozilla.org/mozilla-central/file/tip/netwerk/dns/nsEffectiveTLDService.cpp#l51
>
> Bug 1247835 [1] changed its hashtable usage to a binary search earlier
> this year and we have not noticed any negative fallout.  Performance
> measurements in the bug suggest the binary search might actually be
> slightly faster, and the current structure enables us to easily share
> the lookup structures between processes, as well as being smaller than
> the previous hashtable scheme.  (If we switched to downloading public
> suffix lists--bug 1083971 [2]--the sharing would presumably go away,
> but we'd still get the size wins.)
>
> -Nathan
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1247835
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1083971
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Go Faster] WebCompat Go Faster Add-on

[Benjamin Smedberg]

On Mon, Jun 27, 2016 at 2:26 PM, Cory Price  wrote:

>
> On Mon, Jun 27, 2016 at 11:05 AM, Justin Dolske 
> wrote:
>
>> What's the policy for reviews and testing with this addon?
>>
>
> You can see the current process for deploying things in the Go Faster
> documentation (Wiki , Release
> Process
> 
> ).
>
> I've also added this to our system add-on pipeline
>  which we
> discuss in our weekly meetings (invited Mike/Justin).
>

This seems like an inadequate answer to the particular question: who in
particular is the module owner of this code, who is responsible for doing
code review? And who is the QA/QE lead for this addon and what kind of
systems will be used to determine whether a particular webcompat tweak is
working both before before and after deployment?

--BDS

-- 
Benjamin Smedberg
Engineering Manager, Firefox
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [dev-servo] 25% Improvement in page load time!

[Nathan Froyd]

On Mon, Jun 27, 2016 at 2:01 PM, Jet Villegas  wrote:
> Shing Lyu from our Taipei Layout team reports a 25% page load improvement
> in Servo from moving to a hashtable lookup from an iterator search of the
> public suffix list ( https://publicsuffix.org/ )
>
> Should Gecko do the same thing and replace our binary search method?
> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSiteSecurityService.cpp#917

Gecko's public suffix code lives over in netwerk/dns/:

https://hg.mozilla.org/mozilla-central/file/tip/netwerk/dns/nsEffectiveTLDService.cpp#l51

Bug 1247835 [1] changed its hashtable usage to a binary search earlier
this year and we have not noticed any negative fallout.  Performance
measurements in the bug suggest the binary search might actually be
slightly faster, and the current structure enables us to easily share
the lookup structures between processes, as well as being smaller than
the previous hashtable scheme.  (If we switched to downloading public
suffix lists--bug 1083971 [2]--the sharing would presumably go away,
but we'd still get the size wins.)

-Nathan

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1247835
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1083971
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebCompat Go Faster Add-on

[Justin Dolske]

What's the policy for reviews and testing with this addon?

Justin

On Mon, Jun 27, 2016 at 10:51 AM, Mike Taylor  wrote:

> As discussed in the "Platform + Web Compat" session in London, the
> webcompat team intends to build a Go Faster Add-on to give us the ability
> to quickly respond to high profile site compatibility issues in the coming
> quarter(s).
>
> The intent is to be able deploy short-term fixes for high-impact,
> user-facing problems while we work on medium- to long-term fixes (in Gecko,
> or with partners and top sites), without needing to wait on trains.
>
> I've written an explainer doc, with use cases and requirements here:
>
> 
>
> Comments welcome, thanks.
>
> --
> Mike Taylor
> Web Compat, Mozilla
> ___
> 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: MXR permanently offline, please transition to DXR

[Erik Rose]

Thanks for pointing this out! We've increased the contrast in 
https://github.com/mozilla/dxr/commit/a0b7afeb82bc9903d8c80494fb487b93ef280b70. 
Do feel free to file bugs in the future.

Cheers,
Erik

> On Jun 25, 2016, at 0:45 , Philip Chee  wrote:
> 
> MXR uses black text (#00) on a white background (#FF).
> DXR uses grey goop that pretends to be text and gives me eye-strain.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: June 20th to 24th

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *June 20 - June 24* (week 25).


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


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



*RELEASE CHANNEL*
none

*BETA CHANNEL
*
ID  Summary Product Component   Is a regression 
Assigned to
1281120 
Red exclamation icon disappears at first download   Firefox
Downloads Panel
NO  NOBODY
1281152 
[linux] Washed out download protection icons
Firefox Downloads Panel NO  NOBODY
1281174 
Inconsistent download protection allow download message
Firefox Downloads Panel NO  NOBODY
1281388 
	[linux] Artefacts from download animation when downloading dangerous 
and deceptive content

Firefox Downloads Panel NO  NOBODY
1281413 
[Mac] Web page scrolls when scrolling through hello conversations
Core
Panning and Zooming
NO  NOBODY
1281449 
Navigation links glitches from samsung webpage
Core
Graphics: Layers
NO  NOBODY
1281477 
[Mac] Glitches while scrolling through hello conversations
Hello (Loop)
Client
NO  NOBODY
1281764 
	Scrolling up Twitter across transition-threshold between minimizing and 
maximizing the avatar glitches

Core
Layout
NO  NOBODY
1281778 
Overlap when menu bar is activated and window is minimized
Core
Wigdet: Win32
	YES 
 
	NOBODY

1282075 
	Selecting the "Hide Controls" option causes the container area to 
disappear (for audio files played inline)

Toolkit
Video/Audio Controls
NO  NOBODY
1282082 
	Several side effects using the context menu options on 
https://www.yahoo.com/music/

Tech Evangelism
Desktop
NO  NOBODY

*
**AURORA CHANNEL*
none

*NIGHTLY CHANNEL*
none

*ESR CHANNEL*
none

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

Re: MXR permanently offline, please transition to DXR

[Edmund Wong]

Mike Hoye wrote:
> On 2016-06-24 6:20 AM, Philip Chee wrote:
>>
>> I wonder what is necessary to set up an instance of MXR (for comm-*) on
>> our own server (or vps). I would guess PERL, hg, and a Linux VM.
> I've got the impression that comm-* has enough rocks to push up the
> legacy-stack hill already.
> 

Correction:  boulders.  :P



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