Open Bug 1936999 Opened 2 months ago Updated 25 days ago

Perceptable delay before opening new tab after clicking link (Outlook.com)

Categories

(Firefox :: Tabbed Browser, defect, P2)

Product:
Firefox
Component:
Tabbed Browser
Version:
Firefox 133
Type:
defect
Points:
8

Tracking

()

People

(Reporter: e412byoy7, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged][necko-priority-review])

Attachments

(1 file)

raw data (about:support)
52.54 KB, text/plain
Details

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

Steps to reproduce:

Open outlook.com, click on a bugzilla link in a bugzilla.mozilla.com email that opens a bugzilla bugreport in a new tab.

Actual results:

there is a short but noticable delay until the tab opens, even though I run a pretty good Ryzen 3500U that can run at 3.7 GHz (not running on battery, and power profile settings all good)

Expected results:

There should be no noticable delay.

Profile of the issue (compare time between mouse button release and tab appearing, please): https://share.firefox.dev/3ZvL7cF

Please delete Comment 1

Attachment #9443380 - Attachment description: raw data → raw data (about:support)
Summary: performance issue, opening link in new tab takes between 100 to 250ms to open on Ryzen 5 3500U (3.7 GHz) → performance issue, opening link in new tab takes between 100 to 250ms for the new tab to appear/render on Ryzen 5 3500U (3.7 GHz)
Component: Untriaged → Performance
Product: Firefox → Core
Summary: performance issue, opening link in new tab takes between 100 to 250ms for the new tab to appear/render on Ryzen 5 3500U (3.7 GHz) → performance issue, opening link in new tab takes between 100 to 250ms for the new tab to appear/render on mobile 3500U CPU (3.7 GHz) with RAM at 2400 MHz

This bug was moved into the Performance component.

:e412byoy7, could you make sure the following information is on this bug?

  • ✅ For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
  • For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
  • ~~✅ Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.
    ~~

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Flags: needinfo?(e412byoy7)

Confirmed.

Flags: needinfo?(e412byoy7)

I've confirmed this is the case locally. What appears to be happening is that when clicking a link on NewTab, we delay displaying the new tab until we've loaded the root document for the link that was clicked. This probably has two downsides:

  1. On slow network connections a period of unresponsiveness will be perceived that isn't obviously attributed to network slowness.
  2. Work that needs to be done to render the new tab and could be done during the idle time while waiting for the network response now potentially gets done during a period where it competes with work being done to render the page.

I suspect we'll want to change this.

Component: Performance → New Tab Page
Product: Core → Firefox
Summary: performance issue, opening link in new tab takes between 100 to 250ms for the new tab to appear/render on mobile 3500U CPU (3.7 GHz) with RAM at 2400 MHz → Newtab delays opening a new tab until the root document for a clicked link is loaded

I think this is more to do with how and when the platform talks to the front-end to open new tabs up via the nsIBrowserDOMWindow interface, which desktop implements here: https://searchfox.org/mozilla-central/rev/cdfe21b20eacfaa6712dd9821d6383859ce386c6/browser/base/content/browser.js#4124-4521

That's the mechanism that gets invoked by platform to open up new tabs or new windows from link clicks.

Refreshing my memory a bit, I think the decision for doing this happens in platform around here: https://searchfox.org/mozilla-central/rev/cdfe21b20eacfaa6712dd9821d6383859ce386c6/netwerk/ipc/DocumentLoadListener.cpp#2029-2059

That ostensibly lives inside of Necko, so I'm going to put this in Core :: Networking for now - though maybe Core :: DOM: Navigation also makes sense.

Component: New Tab Page → Networking
Product: Firefox → Core
Summary: Newtab delays opening a new tab until the root document for a clicked link is loaded → Opening a new tab from a clicked link waits until the root document for the clicked link is loaded before the new tab is opened

Nika, could you please share your insights on the next steps here?

Blocks: necko-perf
Severity: -- → S3
Points: --- → 8
Rank: 4
Flags: needinfo?(nika)
Priority: -- → P2
Whiteboard: [necko-triaged][necko-priority-review]

Looking at the profile, It vaguely appears that the mousedown happened at t~=803ms, and the mouseup and corresponding click event happened at t~=3.371s. It appears this click did not immediately cause the new window to be created for the navigation, as the window.open call from JS isn't initiated until t~=3.476s, about 100ms later. Frontend is told about the new tab creation quickly after this, with the createContentWindowInFrame call at t~=3.479s. This call appears to last ~30ms, spent inserting the new browser, and dispatching a number of events in response to set selectedTab. I see a DisplayList:Paint at t~=3.516s, meaning it probably ~37ms to insert, re-style, layout and paint the new tab.

This window being opened is triggered by JS running on the site, rather than an <a target=_blank> click, meaning that this 100ms delay is actually caused by the site, not Firefox. Looking at the profile, it appears a 91.8ms network fetch(...) for a JSON blob is being done during the time between the click event and the window being opened. I'm guessing outlook is sending a network ping to their servers and waiting for it to complete before beginning the navigation.

TL;DR: The short but noticeable delay before the tab is opened in the case of the profile from comment 3 appears to be caused by the website choosing to implement their own handling of link clicks which first sends a network request to their own server (taking 92ms on its own) before starting the navigation. Firefox is responsible for ~40ms of delay, with DOM/IPC responsible for ~3ms, and frontend/style/layout/painting ~37ms (though ~7ms of this may be us waiting for a vsync).

TL;TL;DR: ~70% of the delay is on the website, and cannot be fixed by Firefox. 

(In reply to Mike Conley (:mconley) (:⚙️) from comment #7)

Refreshing my memory a bit, I think the decision for doing this happens in platform around here: https://searchfox.org/mozilla-central/rev/cdfe21b20eacfaa6712dd9821d6383859ce386c6/netwerk/ipc/DocumentLoadListener.cpp#2029-2059

FYI, this is not the correct caller. The code path you linked is only used for edge-cases around opening a new tab when we decide to load a resource which was marked as <a download> (or similar). I added that code path for the now-disabled view-pdf-attachment-without-downloading stuff from a few years ago (bug 1756980). It shouldn't be being hit most of the time nowadays (I believe we nowadays only hit it for error pages which we want to display after someone clicks on a download link).

If this new tab is instead being loaded by an <a target=_blank> click, it should generally be being called through https://searchfox.org/mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0/dom/ipc/ContentParent.cpp#5306-5308 (as it is in this case). This is fired in response to IPC from the content process, requesting a new tab be opened and then starting a navigation. This will not wait for any network requests before opening the tab.

Moving back to frontend, as the bulk of the delay attributable to Firefox is there, though I think this could probably be closed as this appears to be an outlook.com issue.

Component: Networking → Tabbed Browser
Flags: needinfo?(nika) → needinfo?(mconley)
Product: Core → Firefox

Thanks a lot for analyzing! Shouldn't then at least the tab icon turn into a loading icon for those ~100ms as the website is doing something then, to indicate to the user that it is a website issue not a Firefox issue? In general, when the user clicks a link (which I guess then apparently is some "fake" JavaScript item or so instead of a simple URL?) that should open in a new tab, on any website, and the website then processes the user input before letting the browser open the new tab, shouldn't the tab icon be displaying "loading" as the browser is not responsible for the delay?

Flags: needinfo?(nika)

(In reply to Dan from comment #10)

Thanks a lot for analyzing! Shouldn't then at least the tab icon turn into a loading icon for those ~100ms as the website is doing something then, to indicate to the user that it is a website issue not a Firefox issue? In general, when the user clicks a link (which I guess then apparently is some "fake" JavaScript item or so instead of a simple URL?) that should open in a new tab, on any website, and the website then processes the user input before letting the browser open the new tab, shouldn't the tab icon be displaying "loading" as the browser is not responsible for the delay?

Based on my understanding, there is no navigation happening which would allow us to turn the tab icon into a loading icon for those 100ms, as this is a background HTTP "fetch" request. These happen all of the time in the background of sites in a non-user-interactive way so we wouldn't want to put loading feedback in the tab icon for all background fetches. I believe that Firefox is unaware that there is any intention to open a new tab until after the 100ms.

Flags: needinfo?(nika)
Summary: Opening a new tab from a clicked link waits until the root document for the clicked link is loaded before the new tab is opened → Perceptable delay before opening new tab after clicking link (Outlook.com)

So IS it JavaScript inside of the outlook mail window, can Firefox not realize that it is a URL that the user clicked on (before the 100ms timer)? O_O

Flags: needinfo?(nika)

As far as I can tell from the profile you've linked, as far as Firefox is aware, you clicked on a button which triggered some JS on the webpage, and then 100ms later some JS on the page opens a new tab.

The two events are connected in that we track user activation to allow the new tab to be opened (for popup blocking), but we don't know that the click is going to lead to a window being opened until the window is opened.

Flags: needinfo?(nika)

(In reply to Nika Layzell [:nika] (ni? for response) from comment #11)

I believe that Firefox is unaware that there is any intention to open a new tab until after the 100ms.

But Firefox does know that the user clicked on a link... (when I right click on it it says "open link in new tab", so it correctly identifies it as link... So what else would a left click on a URL do other than opening that URL in either current or a new tab?). Whether the browser "knows" whether the click on the link leads to the URL being loaded in the current tab _OR _a in new "window" (tab) doesn't matter, as either way the user is super confused why _NOTHING _is happening (at first), everytime we click on a URL in Outlook. Please make the favicon in the current tab change to the "throbber" (I think it's called? The loading animation) after a URL click until the clicked URL loads in the current or in a new tab.

Flags: needinfo?(nika)

So what else would a left click on a URL do other than opening that URL in either current or a new tab?

It can do literally anything. Here's a demo. If you hover the link, it will claim to visit this bug, if you right-click and open in new tab, it will open the link as expected, but if you click the link, it will not actually open the URL: https://jsfiddle.net/2ngtb3pa/

Without executing the JS first, the browser has no idea what it has to do. In this site's case, the first thing it does is call preventDefault() to stop the normal behavior from happening! After which it seems to be asking a slow server what to do, and after a lot of roundabouts, it decides to open the link (but if the server replies differently, I guess it'll do something else instead...perhaps give a malicious website warning or something like that?)

Flags: needinfo?(nika)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: