Closed Bug 1572933 Opened 2 months ago Closed Last month

Inspector Stops Working

Categories

(DevTools :: Inspector, defect, P1)

68 Branch
defect

Tracking

(firefox71 fixed)

RESOLVED FIXED
Firefox 71
Tracking Status
firefox71 --- fixed

People

(Reporter: mrforsythexeter, Assigned: daisuke)

References

Details

(Whiteboard: [dt-q])

Attachments

(3 files, 2 obsolete files)

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

Steps to reproduce:

Built a site and tried to inspect an element (http://www.accident-helpline.uk.com)

Actual results:

The developer tools open, however you can't interact with the element inspector

Expected results:

The element inspector should allow you to inspect any of the html

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Inspector
Product: Firefox → DevTools

I can reproduce the problem in Developer Edition, but in Nightly it works fine.

Shaun: do you have the chance to test in Firefox Nightly and see if you can reproduce the problem there? Also, do you have any extensions installed?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mrforsythexeter)
Priority: -- → P1

Martin: I agree, Nightly is working fine.

I tested with both Fx 69 (DevEdition) and Fx 68 (release) but couldn't reproduce the issue myself. This was on macOS though, let me try on Windows.

I just tested on Windows 10, with Fx68, 69 and 70 for good measure, and I can't reproduce there either. What am I missing?
Here are my steps:

In all my tests this worked fine (elements got highlighted as I moved over them, and clicked element got selected).

FF 68.0.2 (win 10) (not clean, plugins installsed, but tested on other FF installs)

I managed to find STR that also reproduce in Nightly:

  • Open Firefox, optionally with a fresh profile
  • Open Devtools and go to the settings page
  • check "Disable http cache"
  • go to https://www.accident-helpline.uk.com/
  • right click -> inspect element anywhere on the page

Devtools ends up in a broken state with no errors in the browser console. One Firefox content process will jump to 100% and be stuck, even when you try to to close the browser.

Whiteboard: [dt-q]
Assignee: nobody → daisuke
Status: NEW → ASSIGNED

I investigated this issue.
The direct reason is that the content of one of CSS in that site was differed from the case of cached and not cached.
You can confirm the difference by check or uncheck the "Disable http cache" using this URL.
https://www.accident-helpline.uk.com/wp-content/cache/autoptimize/css/autoptimize_5a8daa6797e54542e7ecc151006cd0e5.css

Result in case of cached:
The fist line will be
@import url(//www.accident-helpline.uk.com/wp-content/themes/luketom-child/../bridge/style.css);

Result in case of no-cached:
The first line will be
@import "//www.accident-helpline.uk.com/wp-content/themes/luketom-child/../bridge/style.css"
Also, most of line break characters will be deleted.

Then, because the number of line was different, the parsing of regex fails (and take toooo much time) at https://searchfox.org/mozilla-central/source/devtools/server/actors/styles.js#2153-2156 and make DevTools broke.

As like this case, we might need to think how we should process if the CSS content which is loaded in DevTools is different from the content which web page loaded.
I wonder if borrowing the content Web page loaded as it is might be ideal though, we don't seems have such the mechanism and method yet.
Thus, since it might take time to implement above, I will try to avoid as following for this time:

  1. Count lines of the content in the CSS
  2. If the number is less than the line number which CSS rule refers (this means the content is different), ignore or fire an error.

If there are other ideas, please letting me know!

There is something weird happening with how devtools fetches stylesheets from the server here.
My feeling is that the cached version of the stylesheet you are seeing is the one devtools creates itself and stores in cache somehow. The server does not have this version of the file at all. It only sends the minified version (the one that has 4 lines only, and that has the @import "// at the beginning).

The fix you are doing might avoid the rule-view from going blank, but this doesn't look like it will solve the root cause of this problem. In fact, the style-editor is also affected here, and your fix probably does not solve this.

I have a feeling that this is due to this function here: https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/devtools/server/actors/stylesheets.js#201

And I think a good start would be to change the options object we pass to honor the cache settings, like so:

const options = {
  loadFromCache: !Services.prefs.getBoolPref("devtools.cache.disabled"),
  policy: Ci.nsIContentPolicy.TYPE_INTERNAL_STYLESHEET,
  charset: getCSSCharset(sheet),
};

I don't know if that will solve it, but I do think we need to get to the bottom of why the stylesheet object and stylesheet text we fetch for it are different here.

Flags: needinfo?(mrforsythexeter) → needinfo?(daisuke)

Thanks Patrick! Let me check again.

Flags: needinfo?(daisuke)
Attached image response.png (obsolete) —

I have re-investigated. As the result, it looks the difference is caused by the algorithm in the server side. But the reason was different from I told last time.

I checked followings with disabling the http cache.

  1. result of the CSS when open the website
  2. result when open the CSS with the URL directly

The results of above are not same. And even we get the CSS by curl command using same request headers as 1, the result is not same to 1, but same to 2.

The attachment is a screenshot of both result. The left side is the screenshot of 1, the right side is 2. As we can see, the differences are not only the content size but also the response headers are (Especially cf-cache-status ??). Since the server field was cloudflare the cause might be the algorithm of cloudflare.
Though I have investigated using DevTools on Chrome Canary, the result was same as ours.

Thus, in order to resolve this problem from the root, the DevTools looks like to need to refer the stylesheet which is completely same as that the website referred.
I am thinking the following approaches for now.

  1. Make completely same environment of loading the website, then load the stylesheet in DevTools.
  2. Keep the loaded content into somewhere(Perhaps, stylesheet object?) , then refers the content from DevTools.
  3. Just show an error message which expresses that the content is different.

What do you think?

Flags: needinfo?(pbrosset)
Attached image response-same-url.png

I'm sorry, the attachment I sent was wrong.
I re-attach the correct screenshot.

Attachment #9087638 - Attachment is obsolete: true

(In reply to Daisuke Akatsuka (:daisuke) from comment #12)

  1. Make completely same environment of loading the website, then load the stylesheet in DevTools.

Sounds like this is the right thing to do. We need to find out what differences exist in how the website requests the stylesheet vs. how devtools requests it. Perhaps devtools isn't sending the same request headers.

  1. Keep the loaded content into somewhere(Perhaps, stylesheet object?) , then refers the content from DevTools.

That would be even better, but I don't think it's easily achievable. After loading/parsing, only the parsed version of the stylesheet remains in memory, not the authored version. And we do need the authored version for devtools (the exact text that was downloaded from the server).\

  1. Just show an error message which expresses that the content is different.

I'm not a huge fan of this because it means we're essentially giving up and letting the user down, but if it comes to that, yes at least showing a message and not breaking the entire inspector would be better than what we have now.

Flags: needinfo?(pbrosset)

I have investigated whether we can resolve by the idea 1.
As the conclusion, it does not look like to matter the request headers and the environment on the browser. So, we can't choose the idea 1.

What I have done to check the resonse with the same request headers are followings:

  • In Network inspector of devtools, click Resend the url and checked the response. The content was different.
  • In Network inspector of devtools, click Open as cURL and executed the command , then checked the response. The content was different.

So, perhaps, the problem is caused from the cache mechanism on the server. The cf-cache-status response header convinced me this behavior. I suppose like followings:

  1. When load the web site, return the CSS (cf-cache-status: MISS). Then, create the cache.
  2. When load after 1st time, return the cached CSS (cf-cache-status: HIT). And the cached content will be different from 1st one.

And if add a parameter to the URL like https://www.accident-helpline.uk.com/wp-content/cache/autoptimize/css/autoptimize_5a8daa6797e54542e7ecc151006cd0e5.css?$timemillis to ignore the cache, we can get correct data. The result also helps us to understand the problem is on server side.

So, we might need to avoid to fetch the CSS. Can we choose the idea 2?
And, I will investigate whether we can resolve this without fetching the CSS again by other way as well.

Flags: needinfo?(pbrosset)

(In reply to Daisuke Akatsuka (:daisuke) from comment #16)

So, we might need to avoid to fetch the CSS. Can we choose the idea 2?

I would love it if we could. My recollection from talking about this a long time ago to people working on gecko is that this was not possible.
If you are able to investigate this and ask the right people about ways to improve this, that'd be great!

Flags: needinfo?(pbrosset)

For now, when we turn on disable cache switch in DevTools[1], web page loads
the contents without using the cache. Furthermore, DevTools as well comes to
load the contents DevTools inspects without using the cache. And, if the loaded
contents from the web page and DevTools was different, becomes impossible to
inspect the content correctly.
Thus, in order to make DevTools refer the same content the web page loaded,
makes DevTools load the contents inspecting from the cache at first, no matter
if disables the switch or not.

When turns on disable cache in DevTools, LOAD_BYPASS_CACHE flag is set into
loadFlags in the docshell.[2] The other hand, the content DevTools inspects
is loaded from a channel DevTools creates with LOAD_FROM_CACHE flag.[3]
However, because this channel is belong to same loadGroup of the docshell,
LOAD_BYPASS_CACHE is inherited and is choosen even if LOAD_FROM_CACHE is set.
Thus, in this patch, we introduce a flag LOAD_FROM_CACHE_PRIORITY which raises
the priority for LOAD_FROM_CACHE above LOAD_BYPASS_CACHE and
LOAD_BYPASS_LOCAL_CACHE.

[1] https://developer.mozilla.org/en-US/docs/Tools/Settings#Advanced_settings
[2] https://searchfox.org/mozilla-central/source/devtools/server/actors/targets/browsing-context.js#1227
[3] https://searchfox.org/mozilla-central/source/devtools/shared/DevToolsUtils.js#542-544

Attachment #9087273 - Attachment is obsolete: true
Attachment #9090318 - Attachment description: Bug 1572933: Introduce a flag to raises the cache priority. r?pbro!,mayhemer! → Bug 1572933: Introduce an attribute to raise the cache priority. r?pbro!,mayhemer!
Pushed by dakatsuka.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/82659174fa83
Introduce an attribute to raise the cache priority. r=pbro,mayhemer
https://hg.mozilla.org/integration/autoland/rev/998907ca7820
Add a test whether DevTools loads from the cache even during disabling the cache. r=pbro
Status: ASSIGNED → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71
See Also: → 1580289
You need to log in before you can comment on or make changes to this bug.