1728529 - Download with content disposition 'disconnects' developer tools inspector

Status: NEW

(DevTools :: Inspector, defect, P3)

Description

[Alex Haan]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

I was developing a webpage where a PDF file download is triggered through javascript (dynamically creating a link to the download url and triggering a click).

Practically it doesn't behave differently from a normal link to a download. So I found a simple reproduction scenario.

• Go to https://trac.ietf.org/trac/httpbis/wiki/ContentDispositionProducers
• Open developer tools.
• See that you can inspect an element (right click: "Inspect (Q)").
• Scroll to the bottom of the page and under "Download in other formats" click on "Plain Text"
• This will start a file download (has content disposition header, yes that's how I found that seemingly random page...).
• Accept the download
• Try to inspect an element on the webpage again.

Tested on Firefox 91 on: Ubuntu 21.04 - Gnome, Windows 10.

Actual results:

The inspector tab does not show content anymore and you cannot inspect an element.

Expected results:

Still be able to use the inspector tool (without closing and reopening the developer tools).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Inspector' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Julian Descottes [:jdescottes]]

Thanks for filing!

We seem to generate a top-level will-navigate event when clicking on a download link, which confuses the inspector (as well as many other devtools panels: debugger, netmonitor, styleeditor etc...). It assumes we are going to replace the document by another document and starts clearing the UIs.

But the navigation doesn't actually replace the document and it simply triggers a download.

This is clearly a duplicate of Bug 1347761 & Bug 1383688, but I would like to keep this one for triage. We have been revisting navigation patterns recently in devtools. This kind of scenario would be much easier to handle if we mostly care about new documents instead of watching for "will-navigate" and similar.

Comment 3

[Julian Descottes [:jdescottes]]

Need to find good meta/project for this bug

Comment 4

[Alexandre Poirot [:ochameau]]

Note that in the following code:
https://searchfox.org/mozilla-central/rev/49b6e60550243b4b4d71d6ab35a3ff2b9a9f7c69/devtools/server/actors/resources/parent-process-document-event.js#76-80
browsingContext.isReplaced might help distinguish downloads from regular navigations.
isReplaced is only true for true navigations.
Unfortunately, it is also false for navigations within the history.
Then, we might identify history navigation via progress.loadType == Ci.nsIDocShell.LOAD_CMD_HISTORY.

May be an early return like this one would ignore download links:

if (!browsingContext.isReplaced && progress.loadType == Ci.nsIDocShell.LOAD_CMD_HISTORY) {
  return;
}

Comment 5

[Julian Descottes [:jdescottes]]

Thanks for the input Alex!

Comment 6

[Julian Descottes [:jdescottes]]

Setting P3 / S3 because this is a long standing issue.