Electrolysis priorities

[Bill McCloskey]

Hi everyone,

At the meeting today, we decided to pick a specific list of bugs that have
the highest priority for dogfooding. I'll propose a few bugs that seem
obvious but everyone should contribute anything that bothers them. Let's
try to finalize the list by next Wednesday. It would be great if we all
start running with e10s to shake out all the most annoying stuff. Once we
have a list that we're happy with, let's talk next Thursday and come up
with a deadline for finishing them. I think sane deadlines can be helpful
to get motivated.

Here's my list:

Make sure copy and paste works - bug 936089
Tooltips (these are really useful for hovering over bugzilla bug numbers) -
bug 938904
Make the file picker work for forms (useful for uploading patches) - bug
910384
Make focusing work properly - bug 904865 is one, probably others
Graphics crashes - bugs 947240, 947213
Alerts and prompts (especially for logging into sites that require
authentication) - bug 899648

Let's also try to prioritize testing. I think we're pretty close to getting
something to work there, and it would be great to have it.

-Bill

[Chris Peterson]

On 1/16/14, 3:45 PM, Bill McCloskey wrote:
> At the meeting today, we decided to pick a specific list of bugs that have
> the highest priority for dogfooding. I'll propose a few bugs that seem
> obvious but everyone should contribute anything that bothers them. Let's
> try to finalize the list by next Wednesday. It would be great if we all
> start running with e10s to shake out all the most annoying stuff. Once we
> have a list that we're happy with, let's talk next Thursday and come up
> with a deadline for finishing them. I think sane deadlines can be helpful
> to get motivated.

Thanks for starting this discussion, Bill!

What do we need regarding OMTC (for dogfood quality)? If Linux OMTC is
troublesome, we could just focus on OS X and Windows for our initial
dogfooding milestone.


Some possible dogfood blockers:

� Bug 960783 - "New window in separate process"
� Bug 910962 - DeallocShmem abort on OS X
� Bug 921935 - [e10s] focusManager doesn't work correctly with e10s
� Bug 722012: [Meta] Implement OMTC on Linux
� Bug 947037 - Enable the software compositor where OMTC is enabled


These bugs would be nice to have to make dogfooding more pleasant:

� Bug 949617: [e10s] Password manager for e10s
� Bug 933540: [e10s] Support Download panel in e10s
� Bug 938359: [e10s] Support middle-click scroll
� Bug 947908 - middle-click to open new tab also goes back in current window
� Bug 959419 - Add "DOMIPCEnabled" flag from crash reports to Socorro Search

> Make sure copy and paste works - bug 936089

btw, copy/paste (from content and address bar) seems to WFM on OS X.


chris

[Benjamin Smedberg]

On 1/16/2014 6:45 PM, Bill McCloskey wrote:
>
> Let's also try to prioritize testing. I think we're pretty close to getting
> something to work there, and it would be great to have it.

Do you mean automated testing or manual testing? As a lurker who doesn't
attend the meeting, is there a summary of what the current e10s
automated testing state is and what things are important/in-progress?

Before we get into large-scale testing, I really want us to add the
checking in bug 950745 for urgent message nested event loops. I'd hate
to do work to have a bunch of tests pass and then discover fundamental
issues with possibly broken event loops that causes everything to start
failing or crashing again.

--BDS

[Bill McCloskey]

On Fri, Jan 17, 2014 at 6:52 AM, Benjamin Smedberg <benj...@smedbergs.us>wrote:

> On 1/16/2014 6:45 PM, Bill McCloskey wrote:
>
>>
>> Let's also try to prioritize testing. I think we're pretty close to
>> getting
>> something to work there, and it would be great to have it.
>>
>
> Do you mean automated testing or manual testing? As a lurker who doesn't
> attend the meeting, is there a summary of what the current e10s automated
> testing state is and what things are important/in-progress?
>

Mark Hammond is working on getting browser-chrome tests running with
browser.tabs.remote=true. He's had to disable a lot of tests initially, of
course. Our goal is to get something minimal running regularly pretty soon
(hopefully by the end of the month). I'm hopeful that other test suites
will be easier to get running, but we don't have anyone working on those
right now.

I'm not sure if we've decided how to actually run the tests. I think
something like this would be ideal:
- Subset of browser-chrome tests on one platform on every push.
- Occasionally run other test suites on all platforms once a day or so.
The rationale here is that it's probably a lot easier to break the stuff
tested by browser-chrome tests (by adding a random docshell access or
something) than it is to break something in Gecko, which is already being
tested on b2g to some extent.

> Before we get into large-scale testing, I really want us to add the
> checking in bug 950745 for urgent message nested event loops. I'd hate to
> do work to have a bunch of tests pass and then discover fundamental issues
> with possibly broken event loops that causes everything to start failing or
> crashing again.
>

Given that we don't use CPOWs in Firefox too much, perhaps we should just
add an overly conservative assertion here. Something of the form "if we
enter a nested event loop while responding to an urgent message, crash".
Eventually we'll want to implement the various mitigation strategies you
described in the bug, but something simpler should be enough to ease any
concerns about missing major problems during testing. Does that make sense?

-Bill

[Bill McCloskey]

I just tried out a build using a copy of my normal profile. Not
surprisingly, there are a bunch of issues that I wouldn't have foreseen.
Beside coming up with a list of bugs, maybe we should have a less empirical
goal: something like "each of us has to use an e10s browser exclusively for
a week". We could tolerate exceptions where a special window is used for
non-e10s stuff, but generally we want to strive toward real-world usability.

-Bill


On Fri, Jan 17, 2014 at 1:02 AM, Chris Peterson <cpet...@mozilla.com>wrote:

> On 1/16/14, 3:45 PM, Bill McCloskey wrote:
>
>> At the meeting today, we decided to pick a specific list of bugs that have
>> the highest priority for dogfooding. I'll propose a few bugs that seem
>> obvious but everyone should contribute anything that bothers them. Let's
>> try to finalize the list by next Wednesday. It would be great if we all
>> start running with e10s to shake out all the most annoying stuff. Once we
>> have a list that we're happy with, let's talk next Thursday and come up
>> with a deadline for finishing them. I think sane deadlines can be helpful
>> to get motivated.
>>
>

> Thanks for starting this discussion, Bill!
>
> What do we need regarding OMTC (for dogfood quality)? If Linux OMTC is
> troublesome, we could just focus on OS X and Windows for our initial
> dogfooding milestone.
>
>
> Some possible dogfood blockers:
>

> • Bug 960783 - "New window in separate process"
> • Bug 910962 - DeallocShmem abort on OS X
> • Bug 921935 - [e10s] focusManager doesn't work correctly with e10s
> • Bug 722012: [Meta] Implement OMTC on Linux
> • Bug 947037 - Enable the software compositor where OMTC is enabled

>
>
> These bugs would be nice to have to make dogfooding more pleasant:
>

> • Bug 949617: [e10s] Password manager for e10s
> • Bug 933540: [e10s] Support Download panel in e10s
> • Bug 938359: [e10s] Support middle-click scroll
> • Bug 947908 - middle-click to open new tab also goes back in current
> window
> • Bug 959419 - Add "DOMIPCEnabled" flag from crash reports to Socorro
> Search
>
>
>

> Make sure copy and paste works - bug 936089
>>
>

> btw, copy/paste (from content and address bar) seems to WFM on OS X.
>
>
> chris

> _______________________________________________
> dev-tech-electrolysis mailing list
> dev-tech-e...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-electrolysis
>

[Benjamin Smedberg]

On 1/17/2014 4:00 PM, Bill McCloskey wrote:
>> Before we get into large-scale testing, I really want us to add the
>> checking in bug 950745 for urgent message nested event loops. I'd hate to
>> do work to have a bunch of tests pass and then discover fundamental issues
>> with possibly broken event loops that causes everything to start failing or
>> crashing again.
>>
> Given that we don't use CPOWs in Firefox too much, perhaps we should just
> add an overly conservative assertion here. Something of the form "if we
> enter a nested event loop while responding to an urgent message, crash".

I do think that's a basic minimum, but I don't think that it's
sufficient. I picked the particular chain of events in that bug
specifically because it makes our behavior a lot less dependent on the
particular content loaded and whether that content happens to call
alert() at any particular point in time:

* any time we enter content script it could call alert or potentially
enter plugin code, so that needs to be disallowed
* any time we dispatch a DOM event to content it could enter script and
so that needs to be disallowed

Let's start with whatever we can manage, but I do think that before
widespread testing we should have all of them.

--BDS

[Chris Peterson]

On 1/17/14, 1:00 PM, Bill McCloskey wrote:
> - Subset of browser-chrome tests on one platform on every push.
> - Occasionally run other test suites on all platforms once a day or so.
> The rationale here is that it's probably a lot easier to break the stuff
> tested by browser-chrome tests (by adding a random docshell access or
> something) than it is to break something in Gecko, which is already being
> tested on b2g to some extent.

btw, bug 932142 is the tracking bug for fixing the browser-chrome tests.


chris

[Reuben Morais]

On Jan 16, 2014, at 21:45, Bill McCloskey <bill.mccl...@gmail.com> wrote:
> Make sure copy and paste works - bug 936089

As Chris pointed out this WFM on OS X.

> Make the file picker work for forms (useful for uploading patches) - bug
> 910384
> Make focusing work properly - bug 904865 is one, probably others

FWIW, other than the two items above, session restore and proper keyboard shortcut handling is the only thing that's keeping me from using an e10s enabled profile for most of my browsing.

-- reuben

[Chris Peterson]

On 1/17/14, 4:28 PM, Reuben Morais wrote:
> FWIW, other than the two items above, session restore and proper keyboard shortcut handling is the only thing that's keeping me from using an e10s enabled profile for most of my browsing.

Reuben: are the "keyboard shortcut handling" problems you experience bug
937213 ("Some keys stop working when the keyboard layout is US
international", reported by you) or bug 950255 ("Make native key
bindings work with e10s")?


chris

[Chris Peterson]

On 1/17/14, 2:19 PM, Bill McCloskey wrote:
> I just tried out a build using a copy of my normal profile. Not
> surprisingly, there are a bunch of issues that I wouldn't have foreseen.
> Beside coming up with a list of bugs, maybe we should have a less empirical
> goal: something like "each of us has to use an e10s browser exclusively for
> a week". We could tolerate exceptions where a special window is used for

> non-e10s stuff, but generally we want to strive toward real-world usability..

Would the one week of using e10s be the quality bar to meet before
exposing the "New e10s window" menu item to Nightly users?

There's no need to wait for per-windows e10s to use an e10s browser
exclusively. Session restore was the big feature I was waiting for. :)


chris

[Reuben Morais]

On Jan 18, 2014, at 1:31, Chris Peterson <cpet...@mozilla.com> wrote:
> On 1/17/14, 4:28 PM, Reuben Morais wrote:

>> FWIW, other than the two items above, session restore and proper keyboard shortcut handling is the only thing that's keeping me from using an e10s enabled profile for most of my browsing.
>

> Reuben: are the "keyboard shortcut handling" problems you experience bug 937213 ("Some keys stop working when the keyboard layout is US international", reported by you) or bug 950255 ("Make native key bindings work with e10s")?

Probably the latter. I mean text editing shortcuts like Cmd+Left/Right, Cmd+Shift+Left/Right, Ctrl+Left/Right, Ctrl+Shift+Left/Right, Ctrl+A, Ctrl+E, Ctrl+K, etc.

-- reuben

[Reuben Morais]

On Jan 18, 2014, at 2:09, Chris Peterson <cpet...@mozilla.com> wrote:
> On 1/17/14, 2:19 PM, Bill McCloskey wrote:

>> I just tried out a build using a copy of my normal profile. Not
>> surprisingly, there are a bunch of issues that I wouldn't have foreseen.
>> Beside coming up with a list of bugs, maybe we should have a less empirical
>> goal: something like "each of us has to use an e10s browser exclusively for
>> a week". We could tolerate exceptions where a special window is used for

>> non-e10s stuff, but generally we want to strive toward real-world usability..
>
> Would the one week of using e10s be the quality bar to meet before exposing the "New e10s window" menu item to Nightly users?
>
> There's no need to wait for per-windows e10s to use an e10s browser exclusively. Session restore was the big feature I was waiting for. :)

I've been using the ProfileSwitcher add-on [0] to quickly switch between/start my e10s profile (it works on e10s as well). Having per-window e10s rocks, but until then, this helps.

[0] https://addons.mozilla.org/en-US/firefox/addon/profileswitcher/

-- reuben

[Bill McCloskey]

On Fri, Jan 17, 2014 at 8:09 PM, Chris Peterson <cpet...@mozilla.com>wrote:

> Would the one week of using e10s be the quality bar to meet before
> exposing the "New e10s window" menu item to Nightly users?
>

I was thinking it would be one of the requirements for resuming part-time
work on add-ons. I think we could expose the "New e10s window" whenever we
want. I guess we might want to wait until things work well so that we could
have a splashy announcement, but we could implement it and not tell anyone
for a while.

> There's no need to wait for per-windows e10s to use an e10s browser
> exclusively. Session restore was the big feature I was waiting for. :)
>

Yeah, I spent most of today running in an e10s browser. I found a few
bugs in session restore today, but I have a fix that should land in a few
days.

-Bill

[Bill McCloskey]

On Fri, Jan 17, 2014 at 8:22 PM, Reuben Morais <reuben...@gmail.com>wrote:

> Probably the latter. I mean text editing shortcuts like Cmd+Left/Right,
> Cmd+Shift+Left/Right, Ctrl+Left/Right, Ctrl+Shift+Left/Right, Ctrl+A,
> Ctrl+E, Ctrl+K, etc.

I think bug 862519 is what you want.

[Chris Peterson]

On 1/16/14, 3:45 PM, Bill McCloskey wrote:

> At the meeting today, we decided to pick a specific list of bugs that have
> the highest priority for dogfooding. I'll propose a few bugs that seem
> obvious but everyone should contribute anything that bothers them. Let's
> try to finalize the list by next Wednesday. It would be great if we all
> start running with e10s to shake out all the most annoying stuff. Once we
> have a list that we're happy with, let's talk next Thursday and come up
> with a deadline for finishing them. I think sane deadlines can be helpful
> to get motivated.

I filed tracking bug 962370 with the bugs people have suggested here as
possible blockers for basic dogfooding

https://bugzilla.mozilla.org/showdependencytree.cgi?id=962370&maxdepth=1&hide_resolved=1

Are there any bugs we want to add or remove from this proposed list?


chris