1800916 - Cannot select or click html response web developer tools - network tab

Status: VERIFIED FIXED

(DevTools :: Netmonitor, defect, P2)

Description

[pavlovp]

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

Steps to reproduce:

Debugging responses from web app.

Actual results:

When response is in rendered html format I cannot copy any parts of it.

Expected results:

I would like to be able to copy rendered html response.

Comment 1

[Julian Descottes [:jdescottes]]

Can you share more details? If you are using the "Response" panel in the Network tab of DevTools, you can click on the "raw" toggle to see the raw response.

Note that we also had a bug with HTML previews which were rendered blank in many cases, this was fixed in Bug 1797952 (released in Firefox 108), but even then you should be able to use the "raw" toggle I mentioned.

Comment 2

[pavlovp]

Hey, sorry for the lack of details. So, on raw toggle I can copy everything, but on html view cannot copy anything. Noticed that cursor is changing over elements - behaving like real rendered html page, on input it becomes like you can click and write, on button it becomes hand to click etc. About the raw input - it is not very useful for me as I use symfony/var-dumper php package, which returns flavored html dump. So today I've made some tests on my machine and here are some details:

Ubuntu Studio 22.04
KDE Plasma Version: 5.24.6
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 5.15.0-53-lowlatency (64-bit)
Graphics Platform: X11
Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics

Firefox 107.0
Firefox Developer Edition 108.0b2 (64-bit) With add-ons turned off

Windows 10 Pro
Version: 21H2
OS Build: 19044.1645

Firefox and Firefox Developer Edition

I forgot to look at versions but I've updated them before test.
Both OSs on the same machine.

Comment 3

[Julian Descottes [:jdescottes]]

Thanks for the additional info!

So you would like to be able to simply select text in the HTML preview. I can see that this is possible in Chrome, although they also process clicks on links in the preview which triggers unexpected navigations.

On our side, we block all mousedown events in the preview at https://searchfox.org/mozilla-central/rev/2f47e3dacf0d773e9c7f363cecf10cfbea490679/devtools/client/netmonitor/src/components/previews/HtmlPreview.js#30-32

We would need a way to prevent links from working but still allow selection.

Comment 4

[pavlovp]

Just tried previous version (106.0.5 (64-bit)) and it is possible to select text and nothing happens when clicking on elements or links.

Comment 5

[Julian Descottes [:jdescottes]]

Thanks for checking, then it must have regressed with Bug 1640689.

Comment 6

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

Set release status flags based on info from the regressing bug 1640689

:ochameau, since you are the author of the regressor, bug 1640689, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 7

[Donal Meehan [:dmeehan]]

:Honza could this be triaged for priority/severity?

Comment 8

[Alexandre Poirot [:ochameau]]

Unfortunately, this is tricky. I'm not aware of any flag on DocShell/BrowsingContext/FrameLoader to prevent navigations.
And this code runs in a distinct process as the loaded document so we only receive mouse events on the <iframe> element, so that we can't differentiate events against links versus others.

Comment 9

[Alexandre Poirot [:ochameau]]

-moz-user-focus: ignore; rule set on the <iframe> should be removed to allow selection.

Moving from mousedown to mouseup allow (+removing user-focus ignore) allow to select and copy (while still disabling links).
But when we mouseup... the selection is no longer stopped and moving the mouse around will keep changing the selection.

Comment 10

[Alexandre Poirot [:ochameau]]

I tried using beforeunload but it doesn't seem to be triggered in this setup.

Comment 11

[Alexandre Poirot [:ochameau]]

If we consider contributing to C++ codebase there might be something to do around this IsNavigationAllowed method:
https://searchfox.org/mozilla-central/rev/5a49163b7012ded5fa1c4da5aa4f8d3f7c85a5e7/docshell/base/nsDocShell.cpp#3320-3333
For now, we only disallow all navigation in case of print preview. We could consider introducing a flag on BrowsingContext to disallow all navigations.

smaug, This is about the patch your reviewed to preview the HTML of network requests.
We have to prevent any kind of navigations when we display these previews.
For now I've been using iframe.onmousedown = e=>e.preventDefault(), but this prevents selecting text and copying it to clipboard.

Is there some other way to disallow all navigation for a given iframe? Or would you consider the addition of BrowsingContext.isNavigationBlocked boolean (or something similar)?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

A BrowsingContext flag sounds reasonable to me.

Comment 13

[Julian Descottes [:jdescottes]]

Just to explain why this worked before bug 1640689: we used a sandbox="" HTML iframe which disallowed navigation.
We now use a XUL iframe to be able to set type=content and remote=true, but this also means we lose the support for sandbox.

Comment 14

[Alexandre Poirot [:ochameau]]

Oh! sandboxFlags are exposed on BrowsingContext and can be set.
iframe.browsingContext.sandboxFlags = 0xFFFF; should be an equivalent of <iframe sandbox=""> that we used to do.

Unfortunately, this seems to be ignored for xul:browser. May be over there? It is specific to html iframes:
https://searchfox.org/mozilla-central/rev/fadd0a14d2a2724ee4733ef73970a2ddd457a43f/dom/base/nsFrameLoader.cpp#2313-2321

Comment 16

[Julian Descottes [:jdescottes]]

(In reply to Alexandre Poirot [:ochameau] from comment #14)

Oh! sandboxFlags are exposed on BrowsingContext and can be set.
iframe.browsingContext.sandboxFlags = 0xFFFF; should be an equivalent of <iframe sandbox=""> that we used to do.

Unfortunately, this seems to be ignored for xul:browser. May be over there? It is specific to html iframes:
https://searchfox.org/mozilla-central/rev/fadd0a14d2a2724ee4733ef73970a2ddd457a43f/dom/base/nsFrameLoader.cpp#2313-2321

Olli, do you know if we could apply the sandbox flags to a XUL iframe, or if there is another way to prevent any navigation without blocking mousedown (and therefore text selection)?

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

Perhaps we could support sandbox also on xul:browser, that might be the easiest solution here?

Comment 18

[Julian Descottes [:jdescottes]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #17)

Perhaps we could support sandbox also on xul:browser, that might be the easiest solution here?

Sounds good, do you have pointers do start working on this, could you mentor one of us to fix this bug?

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

See how sandbox is implemented for html:iframe? like the link you provided here :)

And I can help when needed.

Comment 21

[Julian Descottes [:jdescottes]]

Also reported on https://discourse.mozilla.org/t/network-tab-response-section/110254

Comment 22

[Alexandre Poirot [:ochameau]]

(In reply to Alexandre Poirot [:ochameau] from comment #14)

Oh! sandboxFlags are exposed on BrowsingContext and can be set.
iframe.browsingContext.sandboxFlags = 0xFFFF; should be an equivalent of <iframe sandbox=""> that we used to do.

Unfortunately, this seems to be ignored for xul:browser. May be over there? It is specific to html iframes:
https://searchfox.org/mozilla-central/rev/fadd0a14d2a2724ee4733ef73970a2ddd457a43f/dom/base/nsFrameLoader.cpp#2313-2321

So sandbox flags on xul:iframe aren't going throught that code. nsFrameLoader::MaybeCreateDocShell isn't called for the iframe created by the netmonitor:
https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/devtools/client/netmonitor/src/components/previews/HtmlPreview.js#26-37

   const iframe = container.ownerDocument.createXULElement("iframe");
    iframe.setAttribute("type", "content");
    iframe.setAttribute("remote", "true");

I imagine that's because it is remote?

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #19)

See how sandbox is implemented for html:iframe? like the link you provided here :)

And I can help when needed.

I tried various ways to do ApplySandboxFlags for xul:iframe without any success:

• nsFrameLoader::MaybeCreateDocShell isn't called for these dom elements
• XULFrameElement::AfterSetAttr is called for nsGkAtoms::sandbox, but mFrameLoader is null
• from XULFrameElement::LoadSrc, mFrameLoader->GetExtantBrowsingContext() is also null
  I haven't identified any obvious place where to apply BrowsingContext.sandboxFlags based on DOM "sandbox" attribute.

But I tried doing it in JS from the netmonitor code creating the iframe:

    const iframe = container.ownerDocument.createXULElement("iframe");
    iframe.setAttribute("type", "content");
    iframe.setAttribute("remote", "true");
    container.appendChild(iframe);
    iframe.browsingContext.sandboxFlags = 0xFFFFF;

For some reason, the sandboxFlags are ignored.
But that puzzles me as this is read without any condition:
https://searchfox.org/mozilla-central/search?q=symbol:_ZNK7mozilla3dom15BrowsingContext15GetSandboxFlagsEv&redirect=false

So I would appreciate some help to make sandboxFlags work for xul:iframe.
Otherwise I can fallback on hacking DocShell::IsNavigationAllowed and introduce yet another BC field:
https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/docshell/base/nsDocShell.cpp#3298-3311

Comment 23

[Alexandre Poirot [:ochameau]]

Otherwise, I was wondering if we should immediately relax restrictions and remove this problematic code:
https://searchfox.org/mozilla-central/rev/df68a65540f2227e27a12ed0b491188e2927f6d5/devtools/client/netmonitor/src/components/previews/HtmlPreview.js#30-32

    iframe.addEventListener("mousedown", e => e.preventDefault(), {
      capture: true,
    });

This is a workaround to disallow any navigation using <a> or <form>.
This is covered by this particular part of the test:
https://searchfox.org/mozilla-central/rev/df68a65540f2227e27a12ed0b491188e2927f6d5/devtools/client/netmonitor/test/browser_net_html-preview.js#101-115

I'm not sure it is so problematic to have navigations to work.
The regressing bug 1640689 actually improved security here by finally using <xul:iframe type="content" remote="true">.
So that any content loaded in this iframe element is loaded:

1. in a content process, instead of parent process before!
2. as a content document, we were only using sandbox attribute before!
   With this new setup, I think we could potentially load any document almost safely?

So that letting links/form do navigation would only be a UX issue as it can be sometimes confusing and there is no way to navigate back.
But I imagine it is still better to allow this little confusion than keeping the restriction that bugs everyone here.

Comment 24

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1800916 - [devtools] Allow interactions with HTML previews in netmonitor.

It might be misleading to allow interactions with HTML previews.
Links/forms may navigate to another URL without any way to navigate back.
But it sounds unlikely this will lead to major security issue,
while letting users copy and paste partial pieces of these previews.

Comment 25

[Alexandre Poirot [:ochameau]]

For now, we will allow interactions and some navigation may happen in the preview iframe.
We would need to followup on comment 22 to block navigation without blocking copy/paste.

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d5722560ec79
[devtools] Allow interactions with HTML previews in netmonitor. r=devtools-reviewers,bomsy

Comment 27

[Cristian Tuns]

Backed out for causing devtools failures on /browser_webconsole_network_messages_html_preview.js

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | devtools/client/webconsole/test/browser/browser_webconsole_network_messages_html_preview.js | Verify that link and form are both disabled and the HTML content stays the same - "<html><head></head><body>Redirected!</body></html>" == "<html><head><meta charset="utf8"></head><body>Fetch 3<a href="http://localhost:50442/redirect.html\">link</a> -- <form action="http://localhost:50442/redirect.html\"><input type="submit\

Comment 28

[Alexandre Poirot [:ochameau]]

Cristian, I removed this assertion in this patch... so this backout doesn't look justified.

And I had a green-enough try before pushing (without this failure):
https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=B9dusBOSSIev5Dfkb033rg.0&revision=1a2fe7a76bc00fdcce82f66868eb1e58d49f8727

Comment 29

[Cristian Tuns]

Hi, my backfills look like it is failing starting with your push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=1155668&searchStr=windows%2C10%2Cx64%2C2004%2Cwebrender%2Copt%2Cmochitests%2Ctest-windows10-64-2004-qr%2Fopt-mochitest-devtools-chrome%2Cdt&tochange=97a258c20ec57449539ed763fdeeaea5fdb73f96&fromchange=00457e81fec0c5620a959eb4897a642decc8a204&selectedTaskRun=GHZczw5LT0-QGhLvy0vyxQ.0 and also I added the right test on your try push and it fails too.https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&revision=1a2fe7a76bc00fdcce82f66868eb1e58d49f8727&searchStr=Windows%2C10%2Cx64%2C2004%2CWebRender%2Copt%2CMochitests%2Ctest-windows10-64-2004-qr%2Fopt-mochitest-devtools-chrome%2Cdt3&selectedTaskRun=B65TxOJvSIWRIO-h5TDRtQ.0 can you please take another look?
Thanks!

Comment 30

[Alexandre Poirot [:ochameau]]

Oh sorry, I was confused because we were having two distinct tests with the exact same assertion and I missed removing the assertion in the second test!

Comment 31

[Alexandre Poirot [:ochameau]]

I was also confused by the fact that this other test doesn't run on windows while I'm used to push to try only for linux...

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/25d4eedf4e67
[devtools] Allow interactions with HTML previews in netmonitor. r=devtools-reviewers,bomsy

Comment 33

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/25d4eedf4e67

Comment 34

[Alexandre Poirot [:ochameau]]

Comment on attachment 9316340 [details]
Bug 1800916 - [devtools] Allow interactions with HTML previews in netmonitor.

Beta/Release Uplift Approval Request

• User impact if declined: Can't select copy and paste anything from netmonitor HTML previews
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce: Open the netmonitor, load any page on http/https, select the html page request in the netmonitor and open the Response panel on the right.
  You should be able to copy paste anything in the HTML preview.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch is specific to this focused UI component and only release a restriction which has recently been added.
• String changes made/needed:
• Is Android affected?: No

Comment 35

[Donal Meehan [:dmeehan]]

Comment on attachment 9316340 [details]
Bug 1800916 - [devtools] Allow interactions with HTML previews in netmonitor.

Approved for 111.0b2

Comment 36

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/c5545ed84351

Comment 37

[pavlovp]

Thank you very much <3

Comment 38

[Rares Doghi, Desktop QA]

Hi @Alexandre Poirot , I'm having some difficulties verifying the fix on this issue, I load a page like https://en.wikipedia.org/wiki/Main_Page , open the Network tab in our Dev tools, select the HTML tab from the right panel and then the Response tab.

In our Firefox Release 110 I am unable to select anything from the right panel.
In our Beta 111.0b3 and our latest Nightly build I can select the text but It will not copy anything when Ctrl C is hit on the keyboard.
In our Esr 102.8 I can Select and Copy anything without issues.

Am I missing something ? am I nothing trying to copy from the right place ? Ill attach a screen recording of my issue from all versions.

Comment 39

[Rares Doghi, Desktop QA]

Attachment: 2023-02-20_18h15_40.mp4

Comment 40

[Alexandre Poirot [:ochameau]]

Thanks a lot Rares, you are right, I missed that copy wasn't working... I opened bug 1817857 to fix this.

Comment 41

[Rares Doghi, Desktop QA]

Marking this issue Verified as fixed because the user is able to click and select inside the Network Panel and because we have Bug 1817857 for the Copy and Paste issue. Thanks @Alexandre