User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release) Build ID: 20130815180504 Steps to reproduce: I tend to set a custom URL for my new tab page (instead of using about:newtab) with browser.newtab.url to a regular URL. Doing this apparently never sets the page state to valid/completed, and the URL bar icon remains faded even if the page has done loading. Example, setting browser.newtab.url to https://www.google.se/?gws_rd=cr Actual results: If using a regular URL: faded globe is shown until navigating away If using HTTPS: faded globe is shown, no indication of a secure connection either. This seems to rely on whether there is a renegotiation or redirect (if so, the padlock shows) Expected results: All navigation should properly update the page state and icon, including opening a new tab page this way.
Additional information: the non-updated icon/page state happens on any navigation where the URL happens to be the same as the browser.newtab.url setting (home page, manual navigation, etc.). Even on EV sites that are properly validated (like Twitter), having the URL equal to the pref invalidates the page state and removes the https indicator and site owner name. I've tested this by loading up Twitter, checking the EV state (green lock+site owner name), switching to an about:config tab, pasting the twitter page URL, and swapping back to the Twitter tab which immediately showed the change in state (EV info removed, faded icon). Doing the reverse (changing the pref to something else again) immediately, upon swapping tab, restored the page state indication to what it should be.
Summary: New Tab URL icon is not updated when using custom URL → Page state incorrect when using a custom newTab URL
Confirmed in nightly 26.0a1 (2013-09-02)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Very interesting bug, thank you for filing it Mark. Can you perhaps run http://mozilla.github.io/mozregression/ to find when this behavior appeared in Nightly builds? That will help tremendously in fixing this bug.
I found it's a two-stage regression. In an earlier nightly, the icon/page state becomes invalid (initially removing the favicon, and in later builds fading the generic icon (globe/padlock) at the start of the address bar. Secure sites keep their ID panel and secure state indicated. The second regression completely removes the secure state indication in the ID panel as well, and leaves the address bar without SSL indication (ID panel no longer shows). Regression windows for both regressions: Icon/pages tate regression: Last good nightly: 2012-03-13 First bad nightly: 2012-03-14 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1ca7a94573f2&tochange=c71845b3b2a6 ID panel regression: Last good nightly: 2012-05-27 First bad nightly: 2012-05-28 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=133aa3a2ef0a&tochange=79262a88881d
(In reply to Mark Straver from comment #4) > I found it's a two-stage regression. > > In an earlier nightly, the icon/page state becomes invalid (initially > removing the favicon, and in later builds fading the generic icon > (globe/padlock) at the start of the address bar. Secure sites keep their ID > panel and secure state indicated. > > The second regression completely removes the secure state indication in the > ID panel as well, and leaves the address bar without SSL indication (ID > panel no longer shows). > > Regression windows for both regressions: > > > Icon/pages tate regression: > Last good nightly: 2012-03-13 > First bad nightly: 2012-03-14 > > Pushlog: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=1ca7a94573f2&tochange=c71845b3b2a6 Suspected changeset: http://hg.mozilla.org/mozilla-central/rev/bb271ef702c6 (bug 722263) > ID panel regression: > Last good nightly: 2012-05-27 > First bad nightly: 2012-05-28 > > Pushlog: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=133aa3a2ef0a&tochange=79262a88881d Suspected changeset: http://hg.mozilla.org/mozilla-central/rev/af889781505c (bug 667586)
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 24 Branch → 13 Branch
Related: bug 757455
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.