1309631 - responsive design mode stops launching but appears enabled via the hamburger menu

Status: RESOLVED DUPLICATE of bug 1407830

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

Description

[Kamil Jozwiak [:kjozwiak]]

When running responsive design mode in PB and switching back and forth between PB and regular browsing, responsive design mode will get into a weird state where it will completely stop launching and appear "selected" under the hamburger menu. I can reproduce this pretty easily and created a video for illustration.

Video of issue occurring:
* https://youtu.be/lqzZSfgh0jc

STR:

* launch the latest version of m-c
* open a PB window
* load mozilla.org within the PB window
* launch responsive design mode
* close responsive design mode and close the PB window

Repeat the above STR a few times and you'll eventually get into the weird state where responsive design mode stops launching.

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

So far I haven't been able to reproduce this...  I tried several variations and tried to watch the video closely.  Can you think of any more details here?  I'd love to figure this one out!

Comment 2

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

See comment 2.

Comment 3

[Kamil Jozwiak [:kjozwiak]]

:jryans, I spent a bunch of time trying to get some better STR but couldn't really find anything that would reproduce the issue reliably. The closest I've gotten was when I used the STR from comment#0.

I basically used the following:

* launch m-c
* load mozilla.org and switch into RDM a few times via the keyboard shortcut
* open a PB window, load mozilla.org and switch into RDM several times and close the PB window
* go back into the regular window and switch into RDM a few times

After repeating the above steps, I'll eventually manage to reproduce the problem. I've added another YouTube video where I dictated the steps so you have a better idea of what I'm doing. Hopefully it's more helpful than the previous video which was silent.

* https://youtu.be/hPJ5-j5Nq04

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Thanks for this additional details!  I believe I've been able to hit this case, but _only_ with released Nightly builds.  With my local builds, it never seems to happen.  So, that's pretty frustrating for debugging the issue.

My next step is try hacking the files loaded in Nightly to add some logging at least.

Comment 5

[Kamil Jozwiak [:kjozwiak]]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #4)
> So, that's pretty frustrating for debugging the issue.

I had the same results when I tried reproducing it locally :/ I spent a few hours trying to reproduce the case via a local/debug build but couldn't run into this case.

Let me know if there's anything else that I can help out with.

Comment 6

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: Bug 1309631 - Add guards to ensure RDM destroys on tab close.

In the tab close case, RDM destroy has to complete with yielding.  It's possible
to open RDM in a tab and then close the tab before RDM init has finished, which
means any properties set during RDM init can't be assumed to exist.

In this change, we guard all usages of such properties to ensure destroy can
still finish.

Review commit: https://reviewboard.mozilla.org/r/88216/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/88216/

Comment 7

[Alexandre Poirot [:ochameau]]

Comment on attachment 8804073 [details]
Bug 1309631 - Add guards to ensure RDM destroys on tab close.

https://reviewboard.mozilla.org/r/88216/#review87336

Comment 8

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Comment on attachment 8804073 [details]
Bug 1309631 - Add guards to ensure RDM destroys on tab close.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/88216/diff/1-2/

Comment 9

[Kamil Jozwiak [:kjozwiak]]

Mihai, let me know if you need any help verifying this once it lands in m-c.

Comment 10

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

:kjozwiak, I think I have a fix for this, but it's quite hard to be sure.  Could you double check my results?

Since the issue seems easiest to trigger with a build from automation, I'll include both "known bad" and "possibly good" builds from automation.

Here's a "known bad" build:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2d7aa090f066b6479c18a1789266a4efb0007721
macOS opt download: https://queue.taskcluster.net/v1/task/CdBvdeLYTF2LIhK-w_qsyA/runs/0/artifacts/public/build/target.dmg

Here's my current "possibly good" build:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=659711b533748097202c4878c026a10e4f04becf
macOS opt download: https://queue.taskcluster.net/v1/task/GVdSRtXlS_-bKbUoZAx_WA/runs/0/artifacts/public/build/target.dmg

If you do encounter issues, please check either your terminal or the Browser Console[1].  I've added some debug logging messages, so capturing the log may help me understand what you're seeing.

[1]: https://developer.mozilla.org/en-US/docs/Tools/Browser_Console

Comment 11

[Kamil Jozwiak [:kjozwiak]]

> Here's a "known bad" build:
> 
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=2d7aa090f066b6479c18a1789266a4efb0007721
> macOS opt download:
> https://queue.taskcluster.net/v1/task/CdBvdeLYTF2LIhK-w_qsyA/runs/0/
> artifacts/public/build/target.dmg

I went through the STR that I mentioned in comment#0 and made sure that I can still consistently reproduce the original problem.

> Here's my current "possibly good" build:
> 
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=659711b533748097202c4878c026a10e4f04becf
> macOS opt download:
> https://queue.taskcluster.net/v1/task/GVdSRtXlS_-bKbUoZAx_WA/runs/0/
> artifacts/public/build/target.dmg

I couldn't reproduce the bug using the newer build. I spent about an hour trying the STR from comment#0 and never ran into the issue.

However, I did run into another issue when attempting to reproduce the original bug. Sometimes when you're switching into RDM, the current website will appear completely white. When you end up closing the affected tab, you'll notice there's a 3-5 second delay before the tab actually closes. I've managed to reproduce the problem with both builds but it's a lot easier to make it happen with the new build.

Example of the issue occurring:

* https://youtu.be/pWAPAKDa6cA?t=1m29s
* https://youtu.be/pWAPAKDa6cA?t=16s

:jryans, have you seen this before? Should I separate this into a new bug?

Comment 12

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

I haven't had time to come back to this lately.  It's currently in the back log as a low priority issue, since it's hard to hit this case.

Comment 13

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

I strongly suspect this is the same issue now fixed by bug 1407830.

Please file a new bug if we see anything like this occur in the future!