908110 - Page state incorrect when using a custom newTab URL

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect)

Description

[Mark Straver]

Attachment: firefox24beta-newtabfaded1.png

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.

Comment 1

[Mark Straver]

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.

Comment 2

[Paul Silaghi, QA [:pauly]]

Confirmed in nightly 26.0a1 (2013-09-02)

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

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.

Comment 4

[Mark Straver]

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

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

(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)

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Related: bug 757455

Comment 7

[BMO Automation]

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.