Closed Bug 1487284 Opened 2 years ago Closed 2 years ago

DevTools - Responsive Design Mode - on Refresh in RDM No CSS Rules Show


(DevTools :: Responsive Design Mode, defect)

63 Branch
Not set


(firefox-esr60 unaffected, firefox61 unaffected, firefox62 unaffected, firefox63 verified, firefox64 verified)

Firefox 64
Tracking Status
firefox-esr60 --- unaffected
firefox61 --- unaffected
firefox62 --- unaffected
firefox63 --- verified
firefox64 --- verified


(Reporter: josh, Assigned: jdescottes)


(Blocks 1 open bug)


(Keywords: regression)


(2 files)

Attached image DevToolsBug.jpg
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180824192747

Steps to reproduce:

Go to any website, inspect any element, switch into Responsive Design mode and then refresh the page.

Actual results:

Upon refresh of the page in RDM, there are no longer any css rules shown (elements), not even a message to show inspect any elements in some cases.

Expected results:

The CSS rules (elements) should be displaying as per normal after refresh.
I can reproduce this on Mac OS X 10.12, Windows 10 with the latest Nightly 63.0a1(2018-09-02). 
I did some tests and I found out that this is a regression, here is the regression range: 

Last good revision: 8b61609228c997c521223f9b6ea5ded55d31676f
69:08.57 INFO: First bad revision: 20d26085371c10a2b4a9a49a45b2f508bf2b2403
69:08.57 INFO: Pushlog:

Dan, from the pushlog, seems that bug 1450923 caused this regression, can you please take a look?
Severity: normal → major
Component: Untriaged → Responsive Design Mode
Ever confirmed: true
Flags: needinfo?(dbugs)
Keywords: regression
OS: Unspecified → All
Product: Firefox → DevTools
Hardware: Unspecified → All
I think the regression range must be wrong. All bug 1450923 did was change some initial favicons in the file that seeds bookmarks in a new profile.

The STR here won't even be going anywhere near those and wouldn't be able to cause this sort of regression.
Flags: needinfo?(dbugs)
I did another regression range and here is the result: 

Last good revision: 484dc9b59dcaaedc039e5a851cdd6a997f713429
67:43.37 INFO: First bad revision: 3c1c7f965f0faadc2372c6585866cc36ce31413e
67:43.37 INFO: Pushlog:

From the regression range seems that bug 1478995 might be the problem, Dan can you please take a look?
Flags: needinfo?(dmose)
That bug seems unrelated to the STRs? Ovidiu, since you got different results with the two bisect, maybe the STRs are intermittent? 

Note that we also have similar Bug 1486259 on file.
See Also: → 1486259
Hi Julian, the issue is always reproducible with the steps, I can't figure out why the regression results are different.
Duplicate of this bug: 1487704
Did a new bisect, pointing to Bug 1444132 (rev ace2f8e7a9c9), which can explain the issue.
Flags: needinfo?(dmose)
Since Bug 1444132 is a patch queue, I verified that the issue did not happen before the first changeset, and started occuring after the last changeset (to make sure this was not a false positive). 

Since this is a massive refactor, this merely tells us that this issue probably a race condition related to network monitor changes. But we can't simply backout everything or find the issue based on this regression range I think.
Blocks: 1444132
The styles panel needs to fetch stylesheets, which involves asking the webconsole actor to the network-monitor actor to provide the content if it already has been downloaded. 

This relies on using the message manager to communicate between actors in parent and content processes. Switching to RDM makes the content message manager obsolete and I think the network-monitor actor is not notified of this change and misses the request from the console.
I have a fix, working on a test now
Assignee: nobody → jdescottes
Although this fixes the issue at hand, I am not sure what is the long term
plan for spawnActorInParent vs setupInParent? Both methods seem to have similar roles
and we should probably aim to have only one?
Comment on attachment 9006547 [details]
Bug 1487284 - Update message manager in actors spawned in parent after browserSwap;r=yulia

Yulia Startsev [:yulia] has approved the revision.
Attachment #9006547 - Flags: review+
Blocks: 1489200
Pushed by
Update message manager in actors spawned in parent after browserSwap;r=yulia
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Flags: qe-verify+
Comment on attachment 9006547 [details]
Bug 1487284 - Update message manager in actors spawned in parent after browserSwap;r=yulia

Approval Request Comment
[Feature/Bug causing the regression]:1444132
[User impact if declined]:Responsive Design Mode will have empty CSS pane in inspector when reloading page
[Is this code covered by automated tests?]:Yes, added in this patch
[Has the fix been verified in Nightly?]:In progress (flagged qe-verify+ already)
[Needs manual test from QE? If yes, steps to reproduce]:
- open about:newtab
- open inspector
- switch Responsive Design Mode on
- reload page
ER: CSS rules view should display styles and not "No element selected"
[List of other uplifts needed for the feature/fix]:none
[Is the change risky?]:no
[Why is the change risky/not risky?]:This is a javascript fix that only impacts the module at fault here (the network-monitor actor used by the webconsole), so the risk of side effects is limited.
[String changes made/needed]:N/A
Attachment #9006547 - Flags: approval-mozilla-beta?
Comment on attachment 9006547 [details]
Bug 1487284 - Update message manager in actors spawned in parent after browserSwap;r=yulia

Fix for a regresion, uplift approved for 63 beta 5
Attachment #9006547 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Duplicate of this bug: 1489389
I verified this issue on Mac Os X 10.12, Ubuntu 16.04 and Windows 10 x64 with FF Nightly 64.0a1(2018-09-11) and FF beta 63.0b5 and I can confirm the fix.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.