Page state incorrect when using a custom newTab URL

RESOLVED INACTIVE

Status

()

defect
RESOLVED INACTIVE
6 years ago
11 months ago

People

(Reporter: mark, Unassigned)

Tracking

13 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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.
(Reporter)

Updated

6 years ago
Component: Untriaged → Location Bar
(Reporter)

Comment 1

6 years ago
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.
(Reporter)

Updated

6 years ago
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)
Blocks: 742419
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 455553
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.
Flags: needinfo?(mark)
(Reporter)

Comment 4

6 years ago
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
Flags: needinfo?(mark)
(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)
Blocks: 722263, 667586
No longer blocks: 455553, 742419
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 24 Branch → 13 Branch

Comment 7

11 months ago
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.