1497799 - [Firefox Nightly] if I made changes and try to refresh the page in responsive mode, it doesn't update content

Status: RESOLVED DUPLICATE of bug 1502909

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

Description

[Lela]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

I opened the Responsive Design Mode in Firefox Nightly to see the responsive css that I'm developing.


Actual results:

If I try to refresh the page in this mode, it doesn't update the view and the content I'm developing. I have to either close and reopen the Responsive Design Mode or close the page, CTRL + SHIFT + CANC and cancel manually the cache. 


Expected results:

I expected the content to update immediately. It stopped working since few updates ago.

Comment 1

[Lela]

I noticed something interesting: when I click CTRL + SHIFT + R it doesn't always update the page and refresh it. When it is refreshed, I can see my content updated too; if it is not refreshed correctly, I can't see my content updated. 

I noticed this behavior just now because I'm working with modals and I can actually see if it was refreshed correctly or not, since it closes them.

Comment 2

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: STR1.html

@Lela: I cannot reproduce this... do you have some STR?

Here are the STR I am using:
1. Load the attached file (STR1).
2. Open it in Responsive Mode.
3. Change Text 1 in the test case to Text 2.
4. Refresh the page.

Text 2 is displayed as expected.

Comment 3

[Lela]

Attachment: first.jpg

This is the webpage normal

Comment 4

[Lela]

Attachment: after.jpg

This is after I changed url and doesn't update (done a refresh too)

Comment 5

[Lela]

(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #2)
> Created attachment 9017459 [details]
> STR1.html
> 
> @Lela: I cannot reproduce this... do you have some STR?
> 
> Here are the STR I am using:
> 1. Load the attached file (STR1).
> 2. Open it in Responsive Mode.
> 3. Change Text 1 in the test case to Text 2.
> 4. Refresh the page.
> 
> Text 2 is displayed as expected.

@Mike: I created two new attachments of what I can show you to be the problem.
Sometimes even when I change the URL, it doesn't update the content page as it should - even with the refresh - and sometimes it does this when I try to refresh the page while developing things (HTML/CSS most of times). It's totally random; I didn't find a pattern/specific settings in which it happens more then another. 
If I can help in other ways, reach out to me. I'm sorry I can't give you more details about it.

Comment 6

[Lela]

Attachment: after2.jpg

Comment 7

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: Disable HTTP Cache.png

I think the pages are probably cached on your server... have you tried enabling "Disable HTTP Cache" from the DevTools settings page?

Comment 8

[Lela]

(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #7)
> Created attachment 9017527 [details]
> Disable HTTP Cache.png
> 
> I think the pages are probably cached on your server... have you tried
> enabling "Disable HTTP Cache" from the DevTools settings page?

Yeah, I've tried that. I tend to have it always on because Xampp tends to cache a lot html and css.

Comment 9

[Gabriel]

I believe I'm having the same issue. I'm on FF 64.0b3

It is not a caching issue. At least in my case, it seems to be a rendering issue.
If I enable RDM and reload the page, the throbber shows it's reloading but the image is frozen, still showing a "static" image of the previous state of the page.
Switching to another tab and coming back fixes the issue.

It's not easily reproducible, it only happens sometimes, randomly.

https://streamable.com/awii3
Notice that nothing is clickable, no hover styles, etc, and resizing the responsive window doesn't work. But the page is still scrollable, although it looks like some parts aren't fully rendered (in this instance, the footer at the bottom of the page is cut off).

@Lela, is this the same thing that you are experiencing?

Comment 10

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

@lela and @gabriel I have just tried to reproduce this for 40 minutes but have been unsuccessful.

Just a few questions:

1. Is there a website I could access where this happens a lot?
2. Do you have any addons installed?
3. Can you let us know of any errors that appear in the browser console when this happens?
4. Does it make any difference whether touch events are activated or not?
5. How are you opening Responsive Design Mode?
6. Is the toolbox also visible when you are in responsive design mode.
7. Which OS are you using?
8. This could easily be a graphics driver issue... which graphics card are you using?

We will get to the bottom of this but our first challenging is finding a simple way to reproduce the issue.

Comment 11

[Gabriel]

1. I have just realized it happens with any website (ex: https://www.mozilla.org/en-US/) (see steps below)
2. Yes, but I tried starting in Safe Mode, and the issue still occurs
3. https://imgur.com/XN9Lku3 That's the only error. It shows up when enabling Responsive Design Mode.
4. No, it doesn't
5. CTRL + SHIFT + M
6. Which toolbox? If "Browser Toolbox", then no
7. Ubuntu 16.04, with gnome-flashback and Compiz
8. [AMD/ATI] RV710 [Radeon HD 4350/4550]

- Enabling/disabling Hardware Acceleration doesn't make any difference
- It also happens with a fresh profile


I believe I found a way to reproduce the issue:
1. Open https://www.mozilla.org/en-US/
2. Enable RDM (CTRL + SHIFT + M)
3. Switch to another tab *
4. Go back to previous tab *
5. Refresh (F5)
6. Try to resize the RDM window
7. If the issue does not occur, go back to step 3 (you may have to repeat a couple of times)

(*) Sometimes, but not always, it also happens when switching to another window

Comment 12

[Lela]

(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #10)
> @lela and @gabriel I have just tried to reproduce this for 40 minutes but
> have been unsuccessful.
> 
> Just a few questions:
> 
> 1. Is there a website I could access where this happens a lot?
> 2. Do you have any addons installed?
> 3. Can you let us know of any errors that appear in the browser console when
> this happens?
> 4. Does it make any difference whether touch events are activated or not?
> 5. How are you opening Responsive Design Mode?
> 6. Is the toolbox also visible when you are in responsive design mode.
> 7. Which OS are you using?
> 8. This could easily be a graphics driver issue... which graphics card are
> you using?
> 
> We will get to the bottom of this but our first challenging is finding a
> simple way to reproduce the issue.

@Gabriel: I have the same exact issue, you're such a bless because you were able to actually make a video of it! Unfortunately, for privacy matters, I can't show what I'm doing on the website I'm developing so it's difficult for me to actually explain myself clearly without showing things. 

@Mike: 
1. It happens in every websites. 
2. I have two profiles I use frequently: one with web security disabled and an addon for CORS; another one with Colorzilla, Firefox Multi Container Manager and LastPass. 
3. It doesn't appear any kind of errors. 
4. It doesn't. In fact I tried to turn it on, refresh and same thing done while turning it off.
5. CTRL + SHIFT + M
6. If you mean the Browser one, no. 
7. Windows 10 Pro (x64)
8. Intel (HD) Graphics 620

Thank you so much Mike for your kindness and support.

Comment 13

[Lela]

(In reply to Gabriel from comment #11)
> 1. I have just realized it happens with any website (ex:
> https://www.mozilla.org/en-US/) (see steps below)
> 2. Yes, but I tried starting in Safe Mode, and the issue still occurs
> 3. https://imgur.com/XN9Lku3 That's the only error. It shows up when
> enabling Responsive Design Mode.
> 4. No, it doesn't
> 5. CTRL + SHIFT + M
> 6. Which toolbox? If "Browser Toolbox", then no
> 7. Ubuntu 16.04, with gnome-flashback and Compiz
> 8. [AMD/ATI] RV710 [Radeon HD 4350/4550]
> 
> - Enabling/disabling Hardware Acceleration doesn't make any difference
> - It also happens with a fresh profile
> 
> 
> I believe I found a way to reproduce the issue:
> 1. Open https://www.mozilla.org/en-US/
> 2. Enable RDM (CTRL + SHIFT + M)
> 3. Switch to another tab *
> 4. Go back to previous tab *
> 5. Refresh (F5)
> 6. Try to resize the RDM window
> 7. If the issue does not occur, go back to step 3 (you may have to repeat a
> couple of times)
> 
> (*) Sometimes, but not always, it also happens when switching to another
> window

Wow, yeah, it actually happens as you said! I usually work with few tabs and when I'm focused I tend to stay only on one, so I thought it was random, I didn't find that pattern.

Comment 14

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

I still couldn't reproduce the exact issue but I did manage to trigger the following error using your STR and then using the forward and backward buttons:

JavaScript error: chrome://extensions/content/parent/ext-webNavigation.js, line 128: TypeError: chromeWin.gBrowserInit is undefined; can't access its "isAdoptingTab" property

Comment 15

[Gabriel]

Mmmhh... I'm also getting that error when going back/forward in history, but I think it may be unrelated. The issue in question (which occurs when switching tabs/windows) does not trigger that error.

Comment 16

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Another error I can sometimes trigger:
Extension error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.removeSheet]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/ExtensionCommon.jsm :: runSafeSyncWithoutClone :: line 65"  data: no] undefined 65
[[Exception stack
runSafeSyncWithoutClone@resource://gre/modules/ExtensionCommon.jsm:65:12
cleanup/<@resource://gre/modules/ExtensionContent.jsm:367:13
Current stack
runSafeSyncWithoutClone@resource://gre/modules/ExtensionCommon.jsm:67:129
cleanup/<@resource://gre/modules/ExtensionContent.jsm:367:13
]]

Our issues may be different because I am fairly certain this is a race condition easier to trigger with certain hardware combinations than others.

We can fix these three or four errors and see if it also fixes your issue.

Comment 17

[Lela]

(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #16)
> Another error I can sometimes trigger:
> Extension error: [Exception... "Component returned failure code: 0x80004005
> (NS_ERROR_FAILURE) [nsIDOMWindowUtils.removeSheet]"  nsresult: "0x80004005
> (NS_ERROR_FAILURE)"  location: "JS frame ::
> resource://gre/modules/ExtensionCommon.jsm :: runSafeSyncWithoutClone ::
> line 65"  data: no] undefined 65
> [[Exception stack
> runSafeSyncWithoutClone@resource://gre/modules/ExtensionCommon.jsm:65:12
> cleanup/<@resource://gre/modules/ExtensionContent.jsm:367:13
> Current stack
> runSafeSyncWithoutClone@resource://gre/modules/ExtensionCommon.jsm:67:129
> cleanup/<@resource://gre/modules/ExtensionContent.jsm:367:13
> ]]
> 
> Our issues may be different because I am fairly certain this is a race
> condition easier to trigger with certain hardware combinations than others.
> 
> We can fix these three or four errors and see if it also fixes your issue.

It's fine for me Mike, they may be correlated even if it doesn't seem so. 
I'll be waiting for further information about it :) 

Thank you so much

Comment 18

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #16)
> We can fix these three or four errors and see if it also fixes your issue.

Nope, fixing these errors just opens a rabbit hole full of errors.

I have spent most of the day trying to reproduce this and I can't reproduce it on my hardware.

Comment 19

[Gabriel]

I have been using mozregression to pinpoint when the bug was introduced. I'm not 100% sure, because sometimes the steps to reproduce only work after multiple tries, but it looks like the bug was introduced here:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=daa8803c67e40f36494ed2ab7b236e119d6b4ddb&tochange=95d82d6b175103bbc3d85fd6508c5d4fba6eecb1

Comment 20

[Gabriel]

This error (https://imgur.com/XN9Lku3) now makes sense, since the commit from that pushlog involves changes to browser.xml

From my limited understanding, when constructing a browser, this line:
https://searchfox.org/mozilla-central/source/toolkit/content/widgets/browser.xml#1047
is trying to call sessionHistory on a browser (this.webNavigation) but in remote browsers that is not allowed according to this:
https://searchfox.org/mozilla-central/source/toolkit/components/remotebrowserutils/RemoteWebNavigation.js#146

There seems to be missing a special case handling for remote browsers. This looks like it's done in the destructor:
https://searchfox.org/mozilla-central/source/toolkit/content/widgets/browser.xml#1129
but the equivalent is missing in the constructor. Should I post this on bug 1492967 / open a new bug?

Comment 22

[Gingerbread Man]

:bgrins, please have a look at this, in particular comment 19 and comment 20.

:bradwerth, since you're working on bug 1502909, please check if one should be marked as a duplicate of the other.

Comment 23

[Marek]

I have the same problem.
Version: Firefox Developer Edition 65.0b4 (64-bit). Windows 10 Professional. Tested on two different computers and graphics cards Nvidia Quadro P600 (Dell Precision 7820) and Dell Precision T1650 (Nvidia Quadro 2000).
Responsive Desing Mode often freeze and not refresh content, also when changing viewport size. 
Everyfing works fine, but the viewport area is freezed.
Screen show actual view, and do not change after page refresh.
Solution is I have to disable and enable Responsive Desing Mode. But this is very tiring.
It happend on different websites, servers.
I tryed enable / disable hardware acceleration, but this not help.

Comment 25

[BackuPs]

Hi

Same issue here. Tested on various pc's in various countries. also in latest FF developer. If i revert to FF 63 and FF Dev 64B09 the issue is gone. So i reverted the installs as this is unworkable for me to leave design mode and go back in in order to see my changes.

Thanks !

Comment 26

[BackuPs]

Somehow it is related to the use of the inspector to inspect a element. When i have used the inspector the issue on reload not loading the correct css in the design modus starts. I have to leave the design modus and go back in to get the correct css changes that have been made. Very cumbersome.  Any eta on when this is gonna be fixed?

Comment 27

[Brian Grinstead [:bgrins]]

(In reply to Gabriel from comment #20)
> This error (https://imgur.com/XN9Lku3) now makes sense, since the commit
> from that pushlog involves changes to browser.xml
> 
> From my limited understanding, when constructing a browser, this line:
> https://searchfox.org/mozilla-central/source/toolkit/content/widgets/browser.
> xml#1047
> is trying to call sessionHistory on a browser (this.webNavigation) but in
> remote browsers that is not allowed according to this:
> https://searchfox.org/mozilla-central/source/toolkit/components/
> remotebrowserutils/RemoteWebNavigation.js#146
> 
> There seems to be missing a special case handling for remote browsers. This
> looks like it's done in the destructor:
> https://searchfox.org/mozilla-central/source/toolkit/content/widgets/browser.
> xml#1129
> but the equivalent is missing in the constructor.

Sorry for the delay. Bug 1492967 was intending to maintain the old behavior of the two separate XBL bindings, so if you are seeing that come up in the regression window then we should fix it. Here are the lines before that change:

- Remote browser <constructor> https://hg.mozilla.org/mozilla-central/file/525cd5af1b3f/toolkit/content/widgets/remote-browser.xml#l379 
- Non-remote browser <constructor> which contains the line that does the .webNavigation lookup: https://hg.mozilla.org/mozilla-central/file/525cd5af1b3f/toolkit/content/widgets/browser.xml#l800

In the review, :mconley asked about if we should also run the non-remote browser <constructor> for remote browsers: https://phabricator.services.mozilla.com/D6462#inline-25836. Doing some testing during that patch it seemed like we should, which is why we aren't skiping that code path for remote. It's possible that for RDM we hit special case that we don't see in the normal browsers.

> Should I post this on bug 1492967 / open a new bug?

Would changing this to guard against remote browsers fix this bug? If so, we can set this one as blocking bug 1492967 and fix it here.

Comment 28

[Brian Grinstead [:bgrins]]

Setting needinfo for Comment 27

Comment 29

[Brian Grinstead [:bgrins]]

(In reply to Gabriel from comment #20)
> From my limited understanding, when constructing a browser, this line:
> https://searchfox.org/mozilla-central/source/toolkit/content/widgets/browser.
> xml#1047

I think this link is out of date. Are you referring to this line: https://searchfox.org/mozilla-central/rev/732a632f8de409d8240f4a78d8e23c11ebfbf778/toolkit/content/widgets/browser.xml#1059?

Because if so, then in the remote browser case, `this.docShell` would be null and we wouldn't enter the check for `this.webNavigation.sessionHistory`, even without the early return like we have in the destructor.

Comment 30

[Gabriel]

(In reply to Brian Grinstead [:bgrins] from comment #27)
> (In reply to Gabriel from comment #20)
> 
> > Should I post this on bug 1492967 / open a new bug?
> 
> Would changing this to guard against remote browsers fix this bug? If so, we
> can set this one as blocking bug 1492967 and fix it here.

Not sure. The only error I get when reproducing OP's issue is https://imgur.com/XN9Lku3 . So I suppose fixing that error might fix this issue.

(In reply to Brian Grinstead [:bgrins] from comment #29)
> (In reply to Gabriel from comment #20)
> > From my limited understanding, when constructing a browser, this line:
> > https://searchfox.org/mozilla-central/source/toolkit/content/widgets/browser.
> > xml#1047
> 
> I think this link is out of date. Are you referring to this line:
> https://searchfox.org/mozilla-central/rev/
> 732a632f8de409d8240f4a78d8e23c11ebfbf778/toolkit/content/widgets/browser.
> xml#1059?

Yes, that's the line I meant.

> Because if so, then in the remote browser case, `this.docShell` would be
> null and we wouldn't enter the check for
> `this.webNavigation.sessionHistory`, even without the early return like we
> have in the destructor.

I don't understand much, but as far as I can tell, when the exception is thrown, `this.docShell` *does* have a value. Particularly an object of type `XPCWrappedNative_NoHelper`.

Comment 31

[Brian Grinstead [:bgrins]]

(In reply to Gabriel from comment #30)
> (In reply to Brian Grinstead [:bgrins] from comment #27)
> > (In reply to Gabriel from comment #20)
> > 
> > > Should I post this on bug 1492967 / open a new bug?
> > 
> > Would changing this to guard against remote browsers fix this bug? If so, we
> > can set this one as blocking bug 1492967 and fix it here.
> 
> Not sure. The only error I get when reproducing OP's issue is
> https://imgur.com/XN9Lku3 . So I suppose fixing that error might fix this
> issue.
> 
> (In reply to Brian Grinstead [:bgrins] from comment #29)
> > (In reply to Gabriel from comment #20)
> > > From my limited understanding, when constructing a browser, this line:
> > > https://searchfox.org/mozilla-central/source/toolkit/content/widgets/browser.
> > > xml#1047
> > 
> > I think this link is out of date. Are you referring to this line:
> > https://searchfox.org/mozilla-central/rev/
> > 732a632f8de409d8240f4a78d8e23c11ebfbf778/toolkit/content/widgets/browser.
> > xml#1059?
> 
> Yes, that's the line I meant.
> 
> > Because if so, then in the remote browser case, `this.docShell` would be
> > null and we wouldn't enter the check for
> > `this.webNavigation.sessionHistory`, even without the early return like we
> > have in the destructor.
> 
> I don't understand much, but as far as I can tell, when the exception is
> thrown, `this.docShell` *does* have a value. Particularly an object of type
> `XPCWrappedNative_NoHelper`.

Unfortunately I'm not seeing this locally with the STR in Comment 11. Do you have a local build available? If so, could you please check if adding the isRemoteBrowser check in the condition before `this.docShell` and/or early returning in the isRemoteBrowser condition above fixes the issue? If you don't have one, I could make binaries that do that for testing later this week.

Comment 32

[Gabriel]

I just left on vacation and unfortunately can't reproduce this issue on the laptop I took with me (vs the desktop I use at home). So it might depend on hardware?

(In reply to Brian Grinstead [:bgrins] from comment #31)
> Unfortunately I'm not seeing this locally with the STR in Comment 11. 

Do you at least get this error? https://imgur.com/XN9Lku3

> Do you
> have a local build available? If so, could you please check if adding the
> isRemoteBrowser check in the condition before `this.docShell` and/or early
> returning in the isRemoteBrowser condition above fixes the issue? 

I tried but I have no clue what I'm doing :(  I tried modifying browser.xml in omni.ja to put the early return, but even though I could see my changes in the debugger, it simply ignored any change I made. I guess that's not how it works...

> If you
> don't have one, I could make binaries that do that for testing later this
> week.

Yes please. And when I get back home in a few weeks I'll try it. Or perhaps someone else experiencig this issue can try.

Comment 33

[g3nt13m4n]

I can reproduce this issue.

- Firefox: 64.0.
- OS: Fedora 29.
- At least two monitor setup required.

First monitor:
1. Open Firefox.
2. Open DevTools.
3. Enable Responsive Mode.
4. Go to some website you develop in angular/react/any-other-framework that uses development server with autoreload on save function.

Second monitor:
1. Open Visual Studio Code.
2. Make some changes in your website code and save it.

Comment 34

[Brad Werth [:bradwerth]]

I can replicate, and I have some insight into what's going on, and I have a workaround, but not yet a fix.

First, the workaround: If this happens to you, switching to another tab and then back to the RDM tab should restore your ability to resize the RDM viewport.

What appears to be happening is that, on reload, the presShell of the RDM tab is hitting PresShell::SetIsActive(false) from a style flush. This is deactivating the ability of tab to respond to resize events. I'm not sure why this is happening, but it doesn't get activated again until something like a tab switch happens. I should be able to figure out what's going on by digging into the "normal" reload behavior that occurs without the intervening tab switch.

Comment 35

[Brad Werth [:bradwerth]]

This appears to have been fixed by the fix for Bug 1441935, which just landed. I can no longer reproduce it. Can you please confirm the fix in current Nightly?

Comment 36

[Lela]

(In reply to Brad Werth [:bradwerth] from comment #35)

This appears to have been fixed by the fix for Bug 1441935, which just landed. I can no longer reproduce it. Can you please confirm the fix in current Nightly?

Hi, I tried to reproduce it all morning until now and I couldn't. It seems like it was actually fixed!
Thank you Brad!

Comment 37

[Marek]

In my opinion problem still occurs.

Comment 38

[Gabriel]

In my case, the issue was partially fixed. It seems fixed when following the original steps to reproduce mentioned in comment #11.
But if, after repeating those steps a few times, I go to another website (i.e. change the url in the same tab), then the problem happens again: the tab content stays "frozen" with the previous website.

Comment 39

[jman]

• 1,

The problem is not fixed.

When responsive view is opened and i go to another page on same website (click link) it does not show next page,
but if i go to another tab and than come back - it shows the new page.

FF 65.0 (64-bit)
Windows 10

Comment 40

[Brad Werth [:bradwerth]]

I'll try the new Steps to Reproduce.

Comment 41

[Brad Werth [:bradwerth]]

I can't reproduce this on Release 65 nor on Nightly 67. However, I am testing on macOS and this may be platform-specific. Would you please attempt to reproduce on Nightly? If you are unable to reproduce on Nightly, then this may be hitting a related case that is fixed by Bug 1502909 (fixed for all platforms, we hope).

Comment 42

[Gabriel]

I just tried latest nightly and couldn't reproduce the issue. So it seems it has been fixed.

Comment 43

[Patrick Brosset <:pbro>]

Given the descriptions that people have been giving for this problem here, it looks like this is a duplicate of bug 1502909.
This is a rendering issue where the content in RDM appears to be frozen until you switch tabs and come back again.
This was introduced in 64 and fixed in 66.
Now, 65 is in release now, so it does have the problem unfortunately, but applying the fix from 66 (in beta) to 65 (in release) was discussed and the idea discarded. It's just too complex and risky.
So we unfortunately have to live with this problem for a few more weeks until 66 makes it to release (4,5 weeks to be precise).