Closed
Bug 1137087
Opened 10 years ago
Closed 9 years ago
browser_syncui.js causes browser_tabopen_reflows.js to fail on e10s
Categories
(Firefox Graveyard :: Reading List, defect, P5)
Firefox Graveyard
Reading List
Tracking
(e10s+)
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
e10s | + | --- |
People
(Reporter: markh, Unassigned)
References
(Blocks 1 open bug)
Details
Bug 1131413 landed browser_syncui.js, but disabled it in e10s as browser_tabopen_reflows.js then fails. The failing stack includes http://hg.mozilla.org/mozilla-central/file/dd6353d61993/browser/base/content/tabbrowser.xml#l1206.
There are 2 ways I've found to mitigate this:
* Don't create the sync notification bar at http://hg.mozilla.org/mozilla-central/file/dd6353d61993/browser/base/content/browser-syncui.js#l85 - note that I also tried adding the notification bar to browser.xul instead of adding it dynamically and had the same issue there. Some other experiments also lead me to believe the problem is somehow in the notifications code.
* Have browser_tabopen_reflows.js call gURLBar.focus() just before it adds the reflow observer, which skips that if clause pointed at in tabbrowser.xml. Having browser_syncui.js do this at the end of the test doesn't work as later tests cause that to change.
I can't explain why this is only e10s. It also implies that browser_tabopen_reflows.js isn't quite covering everything it should (ie, it should probably arrange to run the test when the URLBar is focused and when the tab itself is)
Tim or Gavin, do you have any ideas? Or thoughts on the severity (ie, I guess it's bad that tabopen reflows are janky once a sync notificationbox has been created)?
Flags: qe-verify-
Flags: needinfo?(ttaubert)
Flags: needinfo?(gavin.sharp)
Flags: firefox-backlog+
Comment 1•10 years ago
|
||
(In reply to Mark Hammond [:markh] from comment #0)
> I can't explain why this is only e10s. It also implies that
> browser_tabopen_reflows.js isn't quite covering everything it should (ie, it
> should probably arrange to run the test when the URLBar is focused and when
> the tab itself is)
Yeah, that might indeed be a good idea.
> Tim or Gavin, do you have any ideas? Or thoughts on the severity (ie, I
> guess it's bad that tabopen reflows are janky once a sync notificationbox
> has been created)?
So why do we add another <notificationbox> to #browser-bottombox? There is already #global-notificationbox in there, can't we just use that? I have no idea thought why inserting a new one in there would cause problems...
Flags: needinfo?(ttaubert)
Updated•10 years ago
|
Flags: needinfo?(gavin.sharp)
Updated•10 years ago
|
Priority: -- → P5
Updated•10 years ago
|
tracking-e10s:
--- → ?
Updated•10 years ago
|
Comment 2•9 years ago
|
||
browser_syncui.js was re-enabled in bug 1093756. browser_tabopen_reflows.js has been working fine.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•