Closed Bug 1319596 Opened 3 years ago Closed 3 years ago

Blank RDM UI tab after restarting Firefox

Categories

(DevTools :: Responsive Design Mode, defect, P1)

defect

Tracking

(firefox52 unaffected, firefox53 verified)

VERIFIED FIXED
Firefox 53
Tracking Status
firefox52 --- unaffected
firefox53 --- verified

People

(Reporter: jryans, Assigned: jryans)

References

Details

(Keywords: regression, Whiteboard: [rdm-v2])

Attachments

(1 file)

STR:

1. Open RDM in some tab
2. Restart Firefox
3. The tab is blank with a location of chrome://devtools/content/responsive.html/index.xhtml
Flags: qe-verify+
Whiteboard: [rdm-v2]
Alternate STR that also works (less restarting):

1. Open RDM in some tab
2. Close the browser window
3. Restore the browser window (History -> Recently Closed Windows -> First window in list)
4. The tab is blank with a location of chrome://devtools/content/responsive.html/index.xhtml
Bug 1310771 changed the contents of session store message that RDM is watching for, so we need to adjust to match the new name.

I'll also try to add a test for this case.
Blocks: 1310771
Keywords: regression
Another alternate STR:

1. Open two tabs in a browser window (so the window doesn't close when closing a tab)
2. Navigate one of them to some web page
3. Open RDM in that same tab
4. Close the RDM tab
5. Restore last closed tab (History -> Recently Closed Tab -> First tab)
6. The tab is blank with a location of chrome://devtools/content/responsive.html/index.xhtml
Comment on attachment 8813921 [details]
Bug 1319596 - Wait for first historychange when starting RDM.

https://reviewboard.mozilla.org/r/95224/#review95528

::: devtools/client/responsive.html/test/browser/browser_tab_restore.js:16
(Diff revision 1)
> +const { TabStateFlusher } = Cu.import("resource:///modules/sessionstore/TabStateFlusher.jsm", {});
> +
> +add_task(function* () {
> +  // Open tab, start RDM, close tab
> +  let tab = yield addTab(TEST_URL);
> +  yield TabStateFlusher.flush(tab.linkedBrowser);

It could be interesting to have a comment about why we need that call to flush!
Attachment #8813921 - Flags: review?(poirot.alex) → review+
Comment on attachment 8813921 [details]
Bug 1319596 - Wait for first historychange when starting RDM.

https://reviewboard.mozilla.org/r/95224/#review95528

> It could be interesting to have a comment about why we need that call to flush!

Okay, added.
Pushed by jryans@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/fe57f5f7b49d
Wait for first historychange when starting RDM. r=ochameau
Backed out in https://hg.mozilla.org/integration/autoland/rev/e61a652b3f58

Odd pattern of intermittent failure: the fairly frequent ASan https://treeherder.mozilla.org/logviewer.html#?job_id=7226156&repo=autoland would say you're losing a race on a slow build, but the fairly frequent Win7 PGO https://treeherder.mozilla.org/logviewer.html#?job_id=7214821&repo=autoland would say you're losing a race on a fast build (and the fairly frequent Win7 debug would say you're losing a race on a median build, or maybe that you aren't actually losing a race at all).
Since this is a bad bug to have, I'll land the fix first and then the test separately once it's fixed.
Keywords: leave-open
Pushed by jryans@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/31ecbfd5aa7b
Wait for first historychange when starting RDM. r=ochameau
Ryan, want to land the test now?
Flags: needinfo?(jryans)
I would like to, but haven't had time to fix the race issues that caused it to be backed out.

Since we've landed the fix at least, maybe it's better resolve this so regression status is more obvious, and possibly re-land the test later if possible.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(jryans)
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53
Duplicate of this bug: 1298811
I have reproduced this bug with Nightly 53.0a1 (2016-11-22) (64-bit) on Windows 7 , 64 Bit ! 

This bug's fix is verified with latest Nightly 

Build  ID  : 20161221030226
User Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
[bugday-20161221]
Tested on Windows 10 and 7, Mac OS X 10.10, Ubuntu 16.04 with FF Nightly 53.0a1(2016-12-29) and I can confirm the fix.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Version: 49 Branch → Trunk
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.