Closed Bug 1562821 Opened 7 months ago Closed 6 months ago

WebProgress events not properly propagated in Responsive Design Mode

Categories

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

69 Branch
defect

Tracking

(firefox-esr60 unaffected, firefox-esr68 unaffected, firefox68 unaffected, firefox69 verified, firefox70 verified)

VERIFIED FIXED
Firefox 70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- verified
firefox70 --- verified

People

(Reporter: kontakt, Assigned: barret)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [dt-q])

Attachments

(4 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

  • Opened FF developer tools in Nightly (69.0a1 (2019-07-01))
  • Confirmed that the Vue.js devtools and React devtools addons are working properly on the respective pages (locally hosted, they are usually disabled in production mode)
  • Activated RDM without a page reload
  • Confirmed that aforementioned addons are still working
  • Reloaded the page to apply the user agent changes

Actual results:

  • Vue.js devtools tab shows "Proxy injection failed"
  • React devtools tab shows nothing and is unable to connect to React

Expected results:

  • Both addons devtools tabs should load as expected and show my components and their properties
Component: General → Responsive Design Mode

Issue persists in Firefox Developer Edition (69.0b1). The bug was not present in the last 68 release of Developer Edition / Beta before the update into version 69.

Refreshing both Nightly and Developer Edition or using a fresh profile without any additional extensions did not solve the issue, either.

The issue is also not present in 67.0.4. To state the obvious: It seems like some change was introduced in the 69 branch that causes this behaviour.

Pinging Brad for any insight into what may have changed between Firefox 68 and 69 which interferes with content scripts from web extensions injected while RDM is open.

Flags: needinfo?(bwerth)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(brennie)
Whiteboard: [dt-q]

On the latest nightly, I can get React Devtools to work via:

  1. Open a page with react
  2. Start RDM
  3. Open console and switch to react devtools panel

However, if I am already in RDM and then

  1. Open a page with React and
  2. Open the React Devtools,

it will fail to load.

I believe some progress listeners are now being called in the wrong order, but I haven't confirmed that yet.

Flags: needinfo?(brennie)
Assignee: nobody → brennie
Status: NEW → ASSIGNED
Regressed by: 1510569

I'm sorry, but I don't have any special insight into this. I don't think anything in changed in RDM that caused this.

Flags: needinfo?(bwerth)

The priority flag is not set for this bug.
:gl, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gl)
Flags: needinfo?(gl)
Priority: -- → P1

Might not be directly related, but other addons seem to be misbehaving in the same way. Responsive viewport fails to display widgets from tools like PerfectPixel or Magnifying Glass. Default Firefox screenshot fails to display either. You can work around this by reloading outside of the RDM, open up the widget, and then entering the RDM again. Should you reload in the RDM again, the same issue returns until you do the workaround again.

The refactoring that happened in bug 1510569 did not properly forward the WebProgress events to the <xul:browser> element in the parent process. Instead, it was attempting to forward them to the <iframe mozbrowser> which would fail since AsBrowser() would return nullptr.

Summary: React and Vue.js devtools addons not working in RDM → WebProgress events not properly propagated in Responsive Design Mode

The work from bug 1510569 that has ported the majority of the nsIWebProgress
event handlers from WebProgressChild/RemoteWebProgress to
BrowserChild/BrowserParent was not properly propogating the events in the
responsive design mode case. The BrowserParent assumed that its frame element
was an nsIBrowser, but in RDM it is an <iframe mozbrowser> which does not
implement nsIBrowser. In the RDM case we now walk up the document in the
BrowserParent tree to find the <xul:browser> and call the event handlers on
that instead.

When in responsive design mode, the browser-child.js script will be loaded by
the <xul:browser> in the parent process, where a BrowserChild does not
exist. Attempting to retrieve this from the DocShell will cause an error,
preventing the script from executing correctly. We now gracefully handle the
case where browser-child.js is loaded in the parent and no BrowserChild
exists.

Depends on D38916

As part of bug 1510569, the majority of the nsIWebProgress event listeners
have moved from the WebProgressChild/RemoteWebProgress to the
BrowserChild/BrowserParent. In responsive design mode, the
RemoteWebProgress previously would update the state of the <iframe mozbrowser> with document URI and title which would be mirrored back to the
<xul:browser> when leaving RDM. However, the event handlers in the
BrowserParent call directly into the <xul:browser>, skipping the <iframe mozbrowser> entirely. Therefore, when RDM is shut down, old state will be
mirroed to the <xul:browser>, leaving it in an inconsistent state. We now
mirror the state from the <xul:browser> to the <iframe mozbrowser> with an
nsIWebProgressListener so that the <iframe mozbrowser> will not clobber the
<xul:browser>'s state when leaving RDM.

Depends on D38917

Pushed by brennie@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ef785c1b1871
Propagate nsIWebProgress events to the <xul:browser> in responsive design mode r=Ehsan
https://hg.mozilla.org/integration/autoland/rev/f55a0b430239
Gracefully handle loading browser-child.js in the parent r=Ehsan
https://hg.mozilla.org/integration/autoland/rev/ef5b5e589da3
Mirror state from the <xul:browser> to the <iframe mozbrowser> when in RDM r=ochameau
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70

I'm still able to produce incorrect state upon leaving RDM with the latest nightly.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

In the last patch of this series, I forgot to sync remoteWebNavigationImpl
state in the progress listener. This patch corrects that.

Blocks: 1568975
Pushed by brennie@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bb9b3b176a9d
Mirror RemoteWebNavigation state from the <xul:browser> to the <iframe mozbrowser> when in RDM r=ochameau
No longer blocks: 1568975
Status: REOPENED → RESOLVED
Closed: 6 months ago6 months ago
Resolution: --- → FIXED

Comment on attachment 9079831 [details]
Bug 1562821 - Propagate nsIWebProgress events to the <xul:browser> in responsive design mode r?Ehsan

Beta/Release Uplift Approval Request

  • User impact if declined: Responsive design mode will not function properly.
    Add-ons such as react devtools and vue devtools will not work in responsive design mode.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patches are mostly just handling error cases and mirroring data that is no longer mirrored. They are quite safe.
  • String changes made/needed:
Attachment #9079831 - Flags: approval-mozilla-beta?
Attachment #9079832 - Flags: approval-mozilla-beta?
Attachment #9079833 - Flags: approval-mozilla-beta?
Attachment #9080699 - Flags: approval-mozilla-beta?

Comment on attachment 9079831 [details]
Bug 1562821 - Propagate nsIWebProgress events to the <xul:browser> in responsive design mode r?Ehsan

Improving error case handling to ensure that RDM works with popular tools like Vue and React. Approved for 69.0b9.

Attachment #9079831 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9079832 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9079833 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9080699 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Confirmed issue with Nightly (69.0a1 (2019-07-01)) on macOS 10.14..
Fix verified with 69.0b9 and 70.0a1 (2019-07-29)

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.