Noticeable delay in updating title with `document.title`
Reported by
tgp...@gmail.com,
May 28 2018
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 Steps to reproduce the problem: 1. Open attached .html file 2. In Chrome, click the three links on the page while paying attention to the page title on the tab. 3. Do the same in other desktop browsers (namely: Safari, Firefox). What is the expected behavior? The page title should update instantly after keydown event, like it happens in other browsers. What went wrong? There's a noticeable delay (~200ms) between calling `document.title"` and Chrome visually updating the title. There's no easy way to actually measure this, but the perceived impression is that the delay gets longer if other DOM manipulations are performed in parallel. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 66.0.3359.181 Channel: stable OS Version: OS X 10.13.4 Flash Version:
,
May 28 2018
,
May 29 2018
,
May 29 2018
Thanks for filing the issue! Able to reproduce the issue on reported chrome version 66.0.3359.181 and on the latest canary 69.0.3443.0 using Mac 10.13.1, Ubuntu 14.04 and Windows 10. As the issue is seen from M60(60.0.3112.0) considering it as Non-Regression and marking it as Untriaged. Note: Upon clicking the three links on page index.html there is a fractional time lag for the change in title of tab(...as mentioned in C#0 i.e.,noticeable delay (~200ms)).
,
May 30 2018
I've attached a slightly updated index.html that also updates the DOM. I did a screen grab and I can see that the DOM updates about 200ms faster than the window title. It looks like DOM does an RPC to update this and that takes some time.
,
May 30 2018
What's the real use case harmed by this? It's not clear to me why it's important that this be changed.
,
May 30 2018
> What's the real use case harmed by this? This is a great question. I should've elaborated on this more: I narrowed this down to being Chrome issue after encountering it when using a library called `react-helmet` that dynamically updates the title and other <head> content in React SPAs. Here's the relevant Github issue: https://github.com/nfl/react-helmet/issues/189 Couple of problems from the issue above (I personally encountered those as well): 1. Because of title updating with a delay, certain third-party scripts (e.g. Google Analytics) are misreporting the page title by grabbing the previous one. 2. On smaller to mid-size desktop screens and in a real-world app, where the content switch happens almost instantly upon navigating, the title switch with a delay adds a clearly visible lag which is quite distracting. It's a bit difficult to explain in words without a demo, with the perceived clunkiness is very noticeable. I'm unable share an actual project to demonstrate the issue, but I'll try and find some time to put together a simple demo with real content.
,
May 30 2018
Hmm. On bullet (1), I'd think the UI issue of when the tabstrip updates is separate from the title visible to script. So distinguishing those is critical -- we'd want script to see the change synchronously regardless of the UI. On (2), it's fair that significant lag can make things feel unresponsive. We have a somewhat-conflicting goal of avoiding title change flickeriness/spam. I don't know how the current algorithm is implemented (that'd be estade@'s territory), but my hope is it'd be something like "allow a change immediately, have that also kick off a timer to coalesce any updates that happen in the next X ms". That way single changes are fine, rapid changes are rate-limited.
,
Jun 8 2018
The DOM value updates synchronously - that is if you set document.title and read it back, you will get back the value you set. It seems like either - react-helmet updates the title in some other way - these 3rd party scripts read the title in some other way - react-helmet is setting the title _after_ the 3rd party scripts have read it It would be great to see a see a reproduction case, ideally something that sets the title of the page to X but logs the title of the page as Y (in an RPC on via console.log etc).
,
Jul 3
Marking this unconfirmed pending a way to reproduce this logging the wrong title.
,
Jul 3
200ms is a HUGE delay for something as apparently simple as setting a window title. As you certainly know, 100ms is the upper limit of reaction time that's considered instantaneous. Even 100ms is a whole lot of time in the inner world of native OS code so it might be sufficient for the goal of coalescing title updates.
,
Jul 3
There's 2 things here - the issue of incorrect behaviour (logging incorrect page title) this seems like the important problem here but I haven't seen a reproduction case or explanation for that. - the issue of the slow UI update, this is annoying but does not seem very serious
,
Jul 4
,
Jul 9
Still looking for a repro case for: """ - the issue of incorrect behaviour (logging incorrect page title) this seems like the important problem here but I haven't seen a reproduction case or explanation for that. """ This more severe issue is a blink issue.
,
Jul 9
,
Jul 10
I think it's best to leave this bug to be entirely about the delay since that lag issue has a clear cause. So I'm setting this to Untriaged since that lag is confirmed. If someone can repro the correctness problem (doesn't have to be a clean repro, "go here and look for this request in the dev console" would be a start), that can be filed as a new bug.
,
Aug 13
The latency is almost certainly caused by this: https://cs.chromium.org/chromium/src/chrome/browser/ui/browser.cc?sq=package:chromium&g=0&l=265 Specifically: // How long we wait before updating the browser chrome while loading a page. const int kUIUpdateCoalescingTimeMS = 200; This coalescing delay also applies when Browser::ScheduleUIUpdate() is called, which happens via: RenderFrameHostImpl::OnUpdateTitle() -> WebContentsImpl::UpdateTitleForEntry() -> WebContentsImpl::NotifyNavigationStateChanged() -> Browser::NavigationStateChanged(). We could remove this latency by adding a special case here I guess. Nobody really owns this code in Browser so I'm going to assign this to avi@ :) Let's do a fix for this in M71.
,
Aug 13
Shall we just turn that dial down?
,
Aug 13
No. Coalescing title changes matters to not having things flicker. See comment 8 for idea (allow a change instantly but have that start a timer so we coalesce changes that happen within the next 200 ms).
,
Nov 19
**UI mass Triage** Adding appropriate labels. tgpett@, still able to repro on chrome latest versions? avi@ please update this thread as per above latest comments. Thanks..!
,
Nov 19
jmukthavaram@ still reproducible in 70.0.3538.102 and Canary. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by dtapu...@chromium.org
, May 28 2018