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)

defect

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+
(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)
Flags: needinfo?(gavin.sharp)
Priority: -- → P5
tracking-e10s: --- → ?
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
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.