Filed by: philringnalda [at] gmail.com https://treeherder.mozilla.org/logviewer.html#?job_id=102642574&repo=mozilla-central https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-win32/1495945875/mozilla-central_win7_vm_test-mochitest-e10s-browser-chrome-7-bm140-tests1-windows-build39.txt.gz

:Gijs - I think this failure started with your changes in bug 1354078. Can you make this test more reliable?

(In reply to Geoff Brown [:gbrown] from comment #5) > :Gijs - I think this failure started with your changes in bug 1354078. Can > you make this test more reliable? This doesn't make sense. That's when the test was added, but it had exactly the same issues as bug 1336839, because the test is basically a duplicate but using photon rather than non-photon menus. It wasn't frequent at all at the time of bug 1354078. As noted in bug 1336839, this increased in frequency at the end of June. The only related change in the menus was bug 1378427, but that happened a week ago, not at the end of June. It seems more likely this has to do with how we bookmark things or how we open new tabs / remoteness-change them (considering this isn't failing at all in non-e10s). The screenshots show that the newly opened tab hasn't loaded example.com yet, so that would cause the 'bookmark all tabs' code to not consider the new page loaded, meaning there's nothing to bookmark. I've tried seeing if using the BrowserTestUtils here helps, but I'm not sure it will. I can't reproduce the failure locally even with --run-until-failure, so it's hard to know what else to try. https://treeherder.mozilla.org/#/jobs?repo=try&revision=504517374d4b7baef8ba9303fbe3c176f8ab878e

Looks like this got fixed by my patch in bug 1336839. We can reopen if this reoccurs.