PSA - With e10s enabled, initial browser in new windows will soon be remote by default

[Mike Conley]

 If you don’t write tests that open browser windows or work on the
front-end of Firefox, you can probably ignore this.

The initial browser in browser.xul is non-remote by default. This means
that as soon as it browses to some URL that can be loaded in the content
process (about:home, for example), we kick off the remoteness flipping
machinery that swaps out that initial browser and puts a remote one down in
its place to load the content in the child process.

In bug 1261842, I’m working on switching things around so that the initial
browser is remote as soon as possible (there’s still some set-up required
in JS, so I can’t just add the remote attribute to that initial browser).
Doing the flip sooner means we don’t have to set up the content viewer for
the non-remote browser (which gets immediately destroyed after the
remoteness flip), which is good for window-opening performance.

Normally, I wouldn’t bother these two mailing lists with this kind of
information, but while working on these patches, I’ve had to fix a bunch of
tests that worked properly under the old assumption (initial browser is
non-remote) but not under the new one (initial browser is remote), and I
wanted to give a PSA on those writing tests that open windows.

Here’s the deal: If you’re writing browser mochitests and you need to open
a window, please use BrowserTestUtils.openNewBrowserWindow. If you need to
trigger window openings via another mechanism (like window.open in
content), but need to do things with the newly opened window, set up a
Promise with BrowserTestUtils.waitForNewWindow. Both of these methods are
doing the right thing in terms of waiting for the new window to set itself
up and for the initial browser to be ready to do things with it.

If you care - here’s why: without them, you run the risk of falling into
the mistake I was seeing in a number of tests, which was opening a new
window, waiting for its load event, telling the initial browser to load
some URI, and then waiting for BrowserTestUtils.browserLoaded to resolve
before proceeding. This technique will fail frequently, because sometimes
the message to load the URI will arrive at content after it has loaded its
initial about:blank, but before the parent has had an opportunity to hear
that the initial about:blank has been loaded. This means that the
browserLoaded Promise will sometimes resolve even though the URI you
requested hasn’t finished (or maybe even started) loading.

Anyhow, with the patches in the bug, I appear to have fixed all of the
tests that fall into this trap - but if you write a new test that’s opening
a window that’s failing frequently and you don’t know why, it might be
because you need to use those BrowserTestUtils methods.

Feel free to follow up with me in this thread or over IRC if there are any
questions or concerns regarding bug 1261842.

Thanks,

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

Re: The Whiteboard Tag Amnesty

[Robert O'Callahan]

On Thu, Jun 9, 2016 at 9:31 PM, Gijs Kruitbosch 
wrote:

> I'm confused. How are keywords not permissionless?


He meant that adding a new keyword requires permission.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The Whiteboard Tag Amnesty

[Gijs Kruitbosch]

I'm confused. How are keywords not permissionless? I frequently see new 
bugs filed with the first keyword from the sorted list 
("ateam-something-or-other") by people who seem to be intent on "just 
filing a bug in bugzilla", that is otherwise contentless. I must assume 
that these people have no bugzilla permission bits set other than those 
granted new accounts.


~ Gijs

On 08/06/2016 22:08, Patrick McManus wrote:
as you note the whiteboard tags are permissionless. That's their 
killer property. Keywords as you note are not, that's their critical 
weakness.


instead of fixing that situation in the "long term" can we please fix 
that as a precondition of converting things? Mozilla doesn't need more 
centralized systems. If they can't be 100% automated to be 
permissionless (e.g. perhaps because they don't scale) then the new 
arrangement of things is definitely worse.


I'll note that even for triage, our eventual system evolved rapidly 
and putting an administrator in the middle to add and drop keywords 
and indicies would have just slowed stuff down. Permissionless to me 
is a requirement.



On Wed, Jun 8, 2016 at 2:43 PM, Kartikaya Gupta > wrote:


What happens after June 24? Is the whiteboard field going to be
removed?

On Wed, Jun 8, 2016 at 4:32 PM, Emma Humphries > wrote:
> tl;dr -- nominate whiteboard tags you want converted to
keywords. Do it by
> 24 June 2016.
>
> We have a love-hate relationship with the whiteboard field in
bugzilla. On
> one hand, we can add team-specific meta data to a bug. On the
other hand,
> it's not a indexed field or a real tag system, making it hard to
parse,
> search, and update.
>
> But creating keywords is a hassle since you have to request them.
>
> The long term solution is to turn whiteboard into proper tag
system, but
> the Bugzilla Team's offering to help with some bulk conversion of
> whiteboard tags your teams use into keywords.
>
> To participate:
>
> 1. Create a Bug in the bugzilla.mozilla.org::Administration
component for each
> whiteboard tag you want to convert.
>
> 2. The bug's description should have the old keyword, the new
keyword you
> want to replace it with, and the description of this new keyword
which will
> appear in the online help.
>
> 3. Make sure your keyword doesn't conflict with existing
keywords, so be
> prepared to rename it. If your keyword is semantically similar to an
> existing keyword or other existing bugzilla field we'll talk you
about a
> mass change to your bugs.
>
> 4. Make the parent bug,
https://bugzilla.mozilla.org/show_bug.cgi?id=1279022,
> depend on your new bug.
>
> 5. CC Emma Humphries on the bug
>
> We will turn your whiteboard tag into a keyword and remove your
old tag
> from the whiteboard tags, so make sure your dashboards and other
tools that
> consume Bugzilla's API are updated to account for this.
>
> Please submit your whiteboard fields to convert by Friday 24
June 2016.
>
> Cheers,
>
> Emma Humphries
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org

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




___
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: Intent to remove: Error Console

[Richard Marti]

On 09.06.2016 08:53, Philip Chee wrote:

On 08/06/2016 22:59, Brian Grinstead wrote:


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


And what is the plan for Thunderbird?


Bug 1243550

Richard

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

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

Re: Intent to remove: Error Console

[Philip Chee]

On 08/06/2016 22:59, Brian Grinstead wrote:

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

And what is the plan for Thunderbird?

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform