1365075 - Inspector does not show element information after reload

Status: VERIFIED FIXED

(DevTools :: Inspector, defect, P2)

Description

[Rv3]

Attachment: 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

[Loic]

Do you have a simple testcase to reproduce the issue?

Comment 2

[Rv3]

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

Comment 3

[Patrick Brosset <:pbro>]

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.

Comment 4

[Loic]

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

Comment 5

[Matteo Ferretti [:zer0] [:matteo]]

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.

Comment 6

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: Bug 1365075 - waiting until the document is loaded if CustomContentContainer is not available;

Review commit: https://reviewboard.mozilla.org/r/139792/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/139792/

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 8

[Matteo Ferretti [:zer0] [:matteo]]

(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

[Patrick Brosset <:pbro>]

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

Comment 10

[Matteo Ferretti [:zer0] [:matteo]]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/139792/diff/1-2/

Comment 11

[Matteo Ferretti [:zer0] [:matteo]]

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.

Comment 12

[Patrick Brosset <:pbro>]

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 13

[Patrick Brosset <:pbro>]

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.

Comment 14

[Matteo Ferretti [:zer0] [:matteo]]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/139792/diff/2-3/

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9113f64dea57
waiting until the document is loaded if CustomContentContainer is not available; r=pbro

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9113f64dea57

Comment 17

[Nathan Froyd [:froydnj]]

Please request uplift on this when you get a chance.  Thanks!

Comment 18

[Sayed [:LiquidO2]]

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

[Md. Rahimul Islam]

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

Comment 20

[Md. Rahimul Islam]

As per Comment 18 & Comment 19, I am marking this bug as verified fixed

Comment 21

[Liz Henry (:lizzard) (relman/hg->git project)]

We're going to build today for the 54 release candidate, so too late for uplift.

Comment 22

[Mihai Boldan, Desktop QA [:mboldan]]

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.