Inspector does not show element information after reload

VERIFIED FIXED in Firefox 55

Status

DevTools
Inspector
P2
normal
VERIFIED FIXED
a year ago
a month ago

People

(Reporter: Rv3, Assigned: zer0)

Tracking

({regression, testcase})

53 Branch
Firefox 55
regression, testcase

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox53- wontfix, firefox54+ wontfix, firefox55+ verified, firefox56 verified)

Details

(URL)

MozReview Requests

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

(Reporter)

Description

a year ago
Created attachment 8867914 [details]
Bogue.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170504105526

Steps to reproduce:

Load page, open inspector, look at content; you'll see the data about the element in the browser side, reload the page and view the data of en element.

I am unable to replicate the bug on other websites; but bug will replicate 100% of time after first reload of page.

HTML file and CSS passes W3C validation with no errors or warning; thus the document should not cause an issue.

I have tried stripping the CSS from the file as well, error persist.

I have tried Firefox restarting Firefox without any modules, error persist.

I have used the repair function of Firefox, error persist.

I have remove Base64 WOFF file from page; error is gone.

The file does not cause any other issue than this display issue nor does it seem to cause issue with other pages.


Actual results:

Inspector show no data about an element after a page reload. This seems to happen solely on this specific HTML file.


Expected results:

Data about element should still show on reload, view attachement for details.

Comment 1

a year ago
Do you have a simple testcase to reproduce the issue?
Component: Untriaged → Developer Tools: Inspector
Flags: needinfo?(rv3superstar)
Keywords: testcase-wanted
(Reporter)

Comment 2

a year ago
This may be the most case specific bug I have ever encountered.

The issue seems to be the "<link>"; removing the reference fixes the issue. I have tested with an empty file, a new file (CSS and HTML), a new domain and it still does the exact same thing. New file name as well.

Tested on multiple machine as well.

Bugged: http://a4innovation.co/test/Test1.htm
Unbugged: http://a4innovation.co/test/Test2.htm
Flags: needinfo?(rv3superstar)
Thanks for filing that bug. I managed to reproduce this issue on Firefox 53 but also on Nightly 55.
Only the highlighter is affected, the rest of the inspector still works.

STR:
- open http://a4innovation.co/test/Test1.htm
- open the inspector
- hover over nodes in the inspector and check that nodes get highlighted in the page
- reload the page
- hover over nodes in the inspector again

==> Nodes do not get highlighted in the page anymore.

After reloading, the following error is logged: NS_ERROR_UNEXPECTED
And it happens in markup.js, here: http://searchfox.org/mozilla-central/rev/ae24a3c83d22e0e35aecfd9049c2b463ca7e045b/devtools/server/actors/highlighters/utils/markup.js#273

When reloading a page, we re-insert the anonymous content used for the highlighter, and since that part fails, the highlighter doesn't show after that.
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true

Comment 4

a year ago
Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bc4ed3faa33e589fcc1b86221d837b98af3551b7&tochange=2594b001d7579e04a9e01e0fc1cd8512311d4b46

Alexandre Poirot — Bug 1151909 - Make the highlighter work on DOMContentLoaded instead of load. r=pbro
Blocks: 1151909
Has Regression Range: --- → yes
status-firefox53: --- → affected
status-firefox54: --- → affected
status-firefox55: --- → affected
tracking-firefox53: --- → ?
tracking-firefox54: --- → ?
tracking-firefox55: --- → ?
Flags: needinfo?(poirot.alex)
Keywords: testcase-wanted → regression, testcase
OS: Unspecified → All
Hardware: Unspecified → All
(Assignee)

Comment 5

a year ago
So, the NS_ERROR_UNEXPECTED is thrown if we can access to the CustomContentContainer in order to add the AnonymousContent. That can happen if we don't have access also to the shell or CanvasFrame. 

On this specific page, apparently, we do not have access to it when we're trying to add the anonymous content, during the "DOMContentLoad" event, it seems that is too early. Not sure why, I believe the css's response – that is not also css valid file – could have something to do with.

I wrote a small patch, where if we don't have access yet to the `CustomContentContainer` when we're trying to add the anonymous content, and we're in the "interactive" state, is trying to add it on "complete" state.
It's probably a workaround – I'd like to understand better why this page behaves like this – but at least it does the trick.
(Assignee)

Updated

a year ago
Assignee: nobody → zer0
Comment hidden (mozreview-request)
Too late to fix in 53, but we could still take the patch in 54 if it lands in m-c and we verify the fix.
status-firefox53: affected → wontfix
tracking-firefox53: ? → -
tracking-firefox54: ? → +
tracking-firefox55: ? → +
Flags: qe-verify+
(Assignee)

Comment 8

a year ago
(In reply to Matteo Ferretti [:zer0] [:matteo] from comment #5)

> So, the NS_ERROR_UNEXPECTED is thrown if we can access to the

typo, sorry, it was "if we can't".

Comment 9

a year ago
mozreview-review
Comment on attachment 8868210 [details]
Bug 1365075 - waiting until the document is loaded if CustomContentContainer is not available;

https://reviewboard.mozilla.org/r/139792/#review143346

Seems like a great fix. Definitely R+'ing this one.
I would really love to see a test for it though. The bug provides a really simple test case we could use I guess. Can you add a test please?

::: devtools/server/actors/highlighters/utils/markup.js:278
(Diff revision 1)
> +    try {
> +      this._content = doc.insertAnonymousContent(node);
> +    } catch (e) {
> +      // If the `insertAnonymousContent` fails throwing a `NS_ERROR_UNEXPECTED`, it means
> +      // we don't have access to a `CustomContentContainer` yet (see bug 1365075).
> +      // At this point, it could only happens on document's interactive state, and we

s/happens/happen

::: devtools/server/actors/highlighters/utils/markup.js:279
(Diff revision 1)
> +      this._content = doc.insertAnonymousContent(node);
> +    } catch (e) {
> +      // If the `insertAnonymousContent` fails throwing a `NS_ERROR_UNEXPECTED`, it means
> +      // we don't have access to a `CustomContentContainer` yet (see bug 1365075).
> +      // At this point, it could only happens on document's interactive state, and we
> +      // need to wait until the `complete` state before insert the anonymous content

s/insert/inserting

::: devtools/server/actors/highlighters/utils/markup.js:282
(Diff revision 1)
> +      // we don't have access to a `CustomContentContainer` yet (see bug 1365075).
> +      // At this point, it could only happens on document's interactive state, and we
> +      // need to wait until the `complete` state before insert the anonymous content
> +      // again.
> +      if (e.result === Cr.NS_ERROR_UNEXPECTED && doc.readyState === "interactive") {
> +        // The next state chage will be "complete" since the current is "interactive"

s/chage/change
Attachment #8868210 - Flags: review?(pbrosset) → review+
Flags: needinfo?(poirot.alex)
Comment hidden (mozreview-request)
(Assignee)

Comment 11

a year ago
Comment on attachment 8868210 [details]
Bug 1365075 - waiting until the document is loaded if CustomContentContainer is not available;

Added the unit test, and the comments addressed in the previous review.

Notice that the unit test doesn't reload the page since it's not needed: for triggering this behavior, the important is that the Toolbox is already opened before loading the page; so that it can try to add the Anonymous Content during the document's interactive state.
Attachment #8868210 - Flags: feedback?(pbrosset)

Comment 12

a year ago
mozreview-review
Comment on attachment 8868210 [details]
Bug 1365075 - waiting until the document is loaded if CustomContentContainer is not available;

https://reviewboard.mozilla.org/r/139792/#review143982
Comment on attachment 8868210 [details]
Bug 1365075 - waiting until the document is loaded if CustomContentContainer is not available;

We talked on IRC. I wasn't sure about the timeout, but you explained it to me.
So I R+'d the commit again in mozreview.
Attachment #8868210 - Flags: feedback?(pbrosset) → feedback+
Comment hidden (mozreview-request)

Comment 15

a year ago
Pushed by mferretti@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9113f64dea57
waiting until the document is loaded if CustomContentContainer is not available; r=pbro
Priority: -- → P2

Comment 16

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/9113f64dea57
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox55: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
status-firefox-esr52: --- → unaffected
Please request uplift on this when you get a chance.  Thanks!
Flags: needinfo?(zer0)

Comment 18

a year ago
I have reproduced this bug with nightly 55.0a1 (2017-05-16) (64-bit) on Deepin OS 15.4, 64bit following the instruction from comment #3

I can verify that this bug is fixed in latest Nightly

Build ID 	20170524100215
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

[bugday-20170524]

Comment 19

a year ago
I have successfully reproduced the bug in firefox Nightly 55.0a1 (2017-05-15) (32-bit) with windows 10 (32 bit) 

Verified as fixed with latest nightly 55.0a1 (2017-05-24) (32-bit)

Build ID:   20170524030204
Mozilla/5.0 (Windows NT 10.0; rv:55.0) Gecko/20100101 Firefox/55.0
QA Whiteboard: [bugday-20170524]

Comment 20

a year ago
As per Comment 18 & Comment 19, I am marking this bug as verified fixed
Status: RESOLVED → VERIFIED
We're going to build today for the 54 release candidate, so too late for uplift.
status-firefox54: affected → wontfix
(Assignee)

Updated

a year ago
Flags: needinfo?(zer0)
I managed to reproduce this issue on Firefox 55.0a1 (2017-03-17), under Windows 10x64.
The issue is no longer reproducible on Firefox 55.0b3, or on Firefox 56.0a1 (2017-06-22).
Tests were performed under Mac OS X 10.11.6, Windows 10x64 and under Ubuntu 16.04x64.
status-firefox55: fixed → verified
status-firefox56: --- → verified
Flags: qe-verify+

Updated

a month ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.