Created attachment 586586 [details] Mockup: Removing the "Connecting..." string Currently, the text string “Connecting…” appears very briefly in the title of a newly-created tab before the text is replaced with “New Tab.” This text should not appear for two reasons. First, because it’s visible for too short a time to be read, and no text we display should be unreadable. Second, because it’s inaccurate, as New Tab uses cached rather data and requires no connection. The tab should be blank before “New Tab” displays, and preferably “New Tab” would be displayed so fast as to appear instantaneous on a new tab.
Hmm. I don't see this (at least in Linux crating a new tab by clicking on the new tab button.) Exactly what OS is this under and how are you opening the new tab where you see this. This sounds like the kind of thing I could actually help fix, but so far can;t duplicate.
I don't see this either. Something like this does happen if you restore a session with blank tabs.
I can't reproduce that. Did you maybe try with an older version of the UX branch? Even when restoring a session with blank tabs (or the new tab page) this doesn't happen for me.
Hardware: x86 → All
Version: 11 Branch → Trunk
(In reply to Tim Taubert [:ttaubert] from comment #3) > I can't reproduce that. Did you maybe try with an older version of the UX > branch? Even when restoring a session with blank tabs (or the new tab page) > this doesn't happen for me. My UX branch was few days out of date. Once I updated, I couldn't reproduce this - I guess this got fixed! I marked "fixed" for now, and will reopen if I see the sucker again.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Reopening, this is valid again (see bug 455553 comment #149).
Created attachment 590066 [details] [diff] [review] patch v1 Prevents "Connecting..." from flickering in the tab title and hides the throbber for the New Tab Page.
Assignee: nobody → ttaubert
Status: REOPENED → ASSIGNED
Attachment #590066 - Flags: review?(gavin.sharp)
I think it has already been said, but the new tab favicon should go away.
(In reply to GE3K0S from comment #7) > I think it has already been said, but the new tab favicon should go away. That's bug 685059.
Created attachment 604316 [details] [diff] [review] patch v1 unrotted
Gavin: I know we talked about this on IRC and the consequences of touching this code are not totally understood, yet. What can I do to bring this into a landable state? It's a rather minor visual glitch but I think we would really profit from having this fixed.
I would also vote for this. It's pretty disturbing when multiple tabs are already opened and the new tab page is activated - especially on slower computers.
We could do this for every in-content page, should I open a new bug?
(In reply to Marco Castelluccio from comment #14) > We could do this for every in-content page, should I open a new bug? that's a good idea.
p1 because this looks like a fairly small fix which should result in less tab bar flicker.
Whiteboard: [Snappy] → [Snappy:p1]
Created attachment 644623 [details] [diff] [review] patch v2 New approach. The mBlank flag on a tab's progress listener indicates that the tab starts blank and we don't want to show the throbber until the first load has finished and we receive STATE_STOP. The previous patch called browser.stop() to stop loading about:blank (which immediately resets the mBlank flag) and then set mBlank to true again. I think the better way to achieve this is to call browser.stop() *before* we create a tab's progress listener. This way there's not artificial STATE_STOP notification that resets mBlank. For bug 764971, we could rename the parameter to something like "aDontShowThrobberForFirstLoad" and see if the URI passed to addTab() is in a list of content pages.
Try is green: https://tbpl.mozilla.org/?tree=Try&rev=8e469328d876 I know we don't have any explicit tests for this but at least we know we didn't break any basic expectations.
Attachment #644623 - Flags: review?(gavin.sharp) → review+
Whiteboard: [Snappy:p1] → [Snappy:P1][fixed-in-fx-team]
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago → 7 years ago
Resolution: --- → FIXED
Whiteboard: [Snappy:P1][fixed-in-fx-team] → [Snappy:P1]
Target Milestone: --- → Firefox 17
This will be good to have on Aurora.
Comment on attachment 644623 [details] [diff] [review] patch v2 [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 455553 User impact if declined: Flickering tab title when opening new tabs. Testing completed (on m-c, etc.): Will be in today's Nightly. Risk to taking this patch (and alternatives if risky): Low risk. String or UUID changes made by this patch: None.
Attachment #644623 - Flags: approval-mozilla-aurora?
Comment on attachment 644623 [details] [diff] [review] patch v2 [Triage Comment] This doesn't meet our typical bar for uplift, but given where we are in the 16 cycle, and the fact that this is low risk, we'll take the polish.
Attachment #644623 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to Alex Keybl [:akeybl] from comment #23) > This doesn't meet our typical bar for uplift, but given where we are in the > 16 cycle, and the fact that this is low risk, we'll take the polish. Awesome, thank you! https://hg.mozilla.org/releases/mozilla-aurora/rev/559bb27b0def
status-firefox16: --- → fixed
Hello, Firefox 14.0.1. Win Vista. I encounter this bug when I create a new blank tab.
This bug was fixed for Firefox 16, so it's expected that you would still see it in Firefox 14.0.1.
Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0 Setting this to verified in 16 beta 2. Verified on Ubuntu 12.04, Mac OS 10.7, Windows 7 and XP. Also checked slower hardware-no tab animation regressions following this fix.
status-firefox16: fixed → verified
You need to log in before you can comment on or make changes to this bug.