Open
Bug 791672
Opened 12 years ago
Updated 2 years ago
page title in tab takes a long time to load
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox18 | - | --- |
People
(Reporter: bhearsum, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression)
I just noticed this today. Sometimes when loading a tab its titlebar remains empty of text (but the favicon is still there) for upwards of 15-20s. It doesn't happen all of the time - about 80% I'd say.
Couldn't find anything in the error console about it.
I've been able to repro through middle clicking an existing page link and ctrl-clicking a bookmark.
Comment 1•12 years ago
|
||
Is this URL specific? Can you share those URLs? I think it might be related to bug 583890.
Reporter | ||
Comment 2•12 years ago
|
||
Well, Bugzilla for one. I loaded this bug by clicking the link in Thunderbird. Then I loaded bug 583890 by middle clicking the link in your comment. I think I've experienced it on yammer too.
Reporter | ||
Comment 3•12 years ago
|
||
I also just noticed that the page title doesn't refresh until I switch to the tab.
Comment 4•12 years ago
|
||
Does setting 'browser.tabs.cropTitleRedundancy' to 'false' fix the issue?
Reporter | ||
Comment 5•12 years ago
|
||
(In reply to Tim Taubert [:ttaubert] from comment #4)
> Does setting 'browser.tabs.cropTitleRedundancy' to 'false' fix the issue?
I did a quick test with 5-6page loads and it seems to have.
Comment 6•12 years ago
|
||
Ok, thank you. I'll mark this as a regression then.
Blocks: 583890
Keywords: regression
Updated•12 years ago
|
tracking-firefox18:
--- → ?
Were any addons in use? Clean session and clean profile?
I'm trying to reproduce, but haven't found a way so far.
What it sounds like would be the |TabLabelModified| event getting lost, but the fact that it gets labeled on switch to tab may indicate something else is going on.
Reporter | ||
Comment 9•12 years ago
|
||
(In reply to Adam [:hobophobe] from comment #8)
> Were any addons in use? Clean session and clean profile?
>
> I'm trying to reproduce, but haven't found a way so far.
>
> What it sounds like would be the |TabLabelModified| event getting lost, but
> the fact that it gets labeled on switch to tab may indicate something else
> is going on.
Yes, I do have some addons:
A Bit Better RTM
Adblock Plus
Add-on Compatibility Reporter
BugzillaJS
Bugzilla Tweaks
Check4Change
Download Statusbar
Firefox Share
FoxClocks
HTTPS-Everywhere
It's all Text!
Lazarus: Form Recovery
Menu Icons Plus
MoCo Authorizer
PDF Viewer
Status-4-Evar
Stylish
Tile Tabs
I'm having trouble repro'ing now after changing the pref back. I'm also unable to repro on a clean profile. I'll leave the pref flipped and continue to see if I can repro.
Reporter | ||
Comment 10•12 years ago
|
||
I repro'ed a few more times today in my non-clean profile. It appears to happen more when the browser is loaded (loading multiple tabs at once, for example).
Comment 11•12 years ago
|
||
Still cannot reproduce; it would be very helpful if those who can would to gather some debug data.
Debug-patched try builds at:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/unusualtears@gmail.com-252fb3befbde/
If you'd rather build it yourself, the debug patch is included with the other two patches on bug 583890 (or use mercurial to pull the revision off try).
You'll need to flip the preference |browser.dom.window.dump.enabled| to |true| to get the output.
Output will be similar to:
===ABRIDGMENT---FOR: [some URL]===
---ABRIDGMENT---BEGIN---HERE---
[...]
---ABRIDGMENT---END---HERE---
When you see a tab that has either no label or "Connecting...", you can look for the URL of the tab in the terminal output.
Include the output here, any coinciding errors from the error console, and what the tab displayed (either "Connecting..." or no label). No need to include the "===ABRIDGMENT---FOR: http://...===" line.
Reporter | ||
Comment 12•12 years ago
|
||
I'll try to repro with that build sometime today, thanks!
Comment 13•12 years ago
|
||
FWIW, this bug seems to have gone away for me (ABICT)
Reporter | ||
Comment 14•12 years ago
|
||
Now that you mention it, I can't repro anymore either. Possibly related, browser.tabs.cropTitleRedundancy doesn't exist in about:config anymore, either.
Comment 15•12 years ago
|
||
The preference browser.tabs.cropTitleRedundancy (and the bug) should only be in the try build. The feature was backed out from nightly, so the bug won't be there.
The bug should show up in in the try build, and you should see the sort of output I mentioned (again, if the preference browser.dom.window.dump.enabled is on).
Comment 16•12 years ago
|
||
(In reply to Adam [:hobophobe] from comment #15)
> The preference browser.tabs.cropTitleRedundancy (and the bug) should only be
> in the try build. The feature was backed out from nightly, so the bug won't
> be there.
Since bug 583890 was backed out, please re-nominate if it relands.
Assignee: nobody → unusualtears
Comment 17•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: unusualtears → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•