I can confirm this error, Responsive Desing Mode often freeze and not refresh.
Version: Firefox Quantum 64.0 (64-bit) on Windows 10 Home.

I can confirm this bug
Responsive design often freeze, does not refresh, including URL change or F5.

It seems to happens when using inspector while responsive design.

Version: Firefox Quantum, 64.0 on Ubuntu 16

Confirmed bug on Firefox v65 (64-bit), Windows 10 Pro

Same, bug on Firefox v65 (64-bit), Windows 10 Pro

Same problem here, Windows 10 Home.

It is not possible to develop website with firefox quantum...
I switched to Waterfox.

I have been trying to reproduce this issue with no luck so far.
I'm testing this on windows 10, which seems to be where most people here encountered the issue.

It would be very helpful if people could share their specific steps for this problem. Maybe there is a specific type of websites where this happens. Maybe something needs to be done first.
My process so far has been: open random websites, open responsive design mode (RDM), open the inspector, select a few elements, and try to refresh or click on links.
So far everything has worked nicely.
I've tried with both touch simulation ON and OFF in RDM.
I've also tried both with devtools.responsive.metaViewport.enabled true and false, just to see if the viewport meta handling code would have any effect.

darfil: you commented last, maybe you have some steps to share? Or a specific URL where this happened?

Hi Patrick,
try to view a local html file in firefox, enable responsive view, then modify the file and refresh the page.

If it doesn't reproduce the bug, try to modify many times the file until you can't view any changes.

(In reply to Patrick Brosset <:pbro> from comment #18)

I have been trying to reproduce this issue with no luck so far.
I'm testing this on windows 10, which seems to be where most people here encountered the issue.

It would be very helpful if people could share their specific steps for this problem. Maybe there is a specific type of websites where this happens. Maybe something needs to be done first.
My process so far has been: open random websites, open responsive design mode (RDM), open the inspector, select a few elements, and try to refresh or click on links.
So far everything has worked nicely.
I've tried with both touch simulation ON and OFF in RDM.
I've also tried both with devtools.responsive.metaViewport.enabled true and false, just to see if the viewport meta handling code would have any effect.

darfil: you commented last, maybe you have some steps to share? Or a specific URL where this happened?

Hello

Do the following steps and you will reproduce the bug:

• Open random website
• Press F12
• Enable responsive utilities
• Change anything (may be css, HTML content, ....)
• Open new tab and open another website
• Come back to the tab with dev tools openned and do something like: Change URL, change aspect ratio, etc ...

Thank you both for your help. I finally managed to reproduce this with Firefox 65 on Windows 10.

What I did:

• open a tab on a website (I tried different sites like gmail login screen, amazon.com, linkedin.com)
• open the inspector, and open RDM (touch simulation is off, and I didn't pick any specif device)
• make a few CSS changes (random, like changing some color, or some element's height)
• open a new tab in the same browser, and inside it navigate to a website (like do a google search)
• come back to the tab with RDM in it
• click the reload page icon

It's not 100% of the times, but it's common.
When it happens, the page just looks as if it didn't refresh. It's frozen in the state it was before hitting refresh.

It looks like a rendering issue. In the background, things seem to continue working fine. The browser tab animates to show that the page is being reloaded. The inspector updates to show the new content. You can click on things in the page (blindly). It looks like you can fill in input fields, etc.
So, the page still works fine, but the pixels inside the RDM viewport are frozen in the previous state. Resizing RDM doesn't do anything either.

Selecting another tab, and then coming back to the RDM one seems to fix the problem (as in, the page inside RDM shows the update content).

There doesn't seem to be any useful error information in the browser console when this happens.
I did see this one: TypeError: chromeWin.gBrowserInit is undefined ext-webNavigation.js:128:1.

But it doesn't only happen when the problem manifests itself.

I also tested on nightly (Firefox 67) but couldn't reproduce the problem over there.

Thank you for your investigation

I did not know switching tabs fix the problem ... by my side, I only turn responsive OFF then ON again.

I had this bug the first time on Ubuntu, then on Windows.

As a web developper, this bug happens often

Basically, I use dev tools to test my CSS before apply on source code
And I always have to switch tabs, to read or close tickets with my customers.

This bug seems to happens when I switch tabs.

So it sounds like this might be a weird interaction between the remote browser and the layer system. i.e. perhaps some messages are not properly making it to the right place to cause us to paint the new content. After talking to mconley it sounds like the current way that responsive design mode works with multiple mozbrowsers is a bit funky so it seems like there's room for something to go wrong there.

Some other questions:

• Does the problem still happen if you switch tabs with the keyboard instead of the mouse?
• Is this a regression in 65? Getting a regression window would be very helpful.'
• Is it necessarily to reload the page for things to go wrong? i.e. does scrolling work before reloading? Or does reloading just make it obvious that it's not repainting?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #24)
Thanks Jeff for spending time looking at this!

So it sounds like this might be a weird interaction between the remote browser and the layer system. i.e. perhaps some messages are not properly making it to the right place to cause us to paint the new content.

That might indeed be the case. RDM relays messages from/to the inner mozbrowser iframe.

After talking to mconley it sounds like the current way that responsive design mode works with multiple mozbrowsers is a bit funky so it seems like there's room for something to go wrong there.

RDM doesn't currently work with multiple mozbrowsers, there's just one. Unless I misunderstood what you meant.

Some other questions:

• Does the problem still happen if you switch tabs with the keyboard instead of the mouse?

Yes it does

• Is this a regression in 65? Getting a regression window would be very helpful.

I'll start working on that now. Since this is not a 100% reproduction rate, it will be a bit harder than usual, but I'll see what I can find.

• Is it necessarily to reload the page for things to go wrong? i.e. does scrolling work before reloading? Or does reloading just make it obvious that it's not repainting?

Yes it seems to be necessary. Before reloading, the page scrolls fine, and the viewport adapts to RDM resizes. After reloading, that's when the freeze occurs.

I found the culprit: bug 1492967, which landed in 64.
Now, since this seems to be working fine in nightly, I'll do a --find-fix regression to find what fixed it.

(In reply to Patrick Brosset <:pbro> from comment #26)

I found the culprit: bug 1492967, which landed in 64.

This tunnel.js diff seems like it could be causing this problem: https://hg.mozilla.org/mozilla-central/diff/95d82d6b1751/devtools/client/responsive.html/browser/tunnel.js
@bgrins: does anything come to mind?

(In reply to Patrick Brosset <:pbro> from comment #26)

I found the culprit: bug 1492967, which landed in 64.
Now, since this seems to be working fine in nightly, I'll do a --find-fix regression to find what fixed it.

And the bug that fixed it is bug 1441935, which landed in 66.

(In reply to Patrick Brosset <:pbro> from comment #27)

(In reply to Patrick Brosset <:pbro> from comment #26)

I found the culprit: bug 1492967, which landed in 64.

This tunnel.js diff seems like it could be causing this problem: https://hg.mozilla.org/mozilla-central/diff/95d82d6b1751/devtools/client/responsive.html/browser/tunnel.js
@bgrins: does anything come to mind?

There's a lot of suspicious looking stuff in that file. The intent there is that since we no longer have multiple XBL bindings, we don't need to flip the attr and wait for "browser" binding to destruct and "remote-browser" binding to construct. Instead we manually destroy the shared binding, then flip the attr, then manually construct it. This means we don't have to do the Services.tm.spinEventLoopUntil thing to wait for layout (https://hg.mozilla.org/mozilla-central/diff/95d82d6b1751/devtools/client/responsive.html/browser/tunnel.js#l1.129). I'm actually wondering why we weren't also spinning event loop when setting it back to the non-remote binding: https://hg.mozilla.org/mozilla-central/diff/95d82d6b1751/devtools/client/responsive.html/browser/tunnel.js#l1.129.

Anyway, this is pretty deep into XBL weirdness, so I'm both not surprised and very happy to hear the Custom Element migration fixed it. Given that the fix is already on Beta, are you fine with this being a wontfix on 65?

(In reply to Brian Grinstead [:bgrins] from comment #29)

Given that the fix is already on Beta, are you fine with this being a wontfix on 65?

Going to pass this on to Martin for the product perspective on this.

I'm taking myself off the bug since I have little insight into the mechanics, and it appears it may be fixed already.

The bug is quite bad and I see complaints spreading on many channels. If there is a chance to uplift this to Fx 65 I'd like to explore it.

Brian, what would it take to uplift the fix to release?

(In reply to Martin Balfanz [:mbalfanz] from comment #32)

The bug is quite bad and I see complaints spreading on many channels. If there is a chance to uplift this to Fx 65 I'd like to explore it.

Brian, what would it take to uplift the fix to release?

It'd be quite a bit of work:

1. We can't uplift the <browser> Custom Element conversion that fixed it, it's too complex. So we'd have to find a make a targeted fix for just this. I have a couple of ideas from Comment 29 but nothing I'm confident about so that would take some work.
2. We'd have to get it tested against a release build and included in a dot release. I just asked in #firefox and it sounds like there's one planned for early next week, but not any others.

Given (2) and that this isn't causing a crash, data loss, etc I'm going to say that realistically this won't make it onto 65 and that we'll have to wait for it to be fixed on release in 66 on 2019-03-19.

Thank you Brian, I really appreciate the explanation. Let's wait for 66 then.

I just realized this was still open, but because of comment 33 and comment 34, we should really close it as a duplicate of bug 1441935. So I'll do this now.