Closed Bug 855691 Opened 7 years ago Closed 7 years ago

Defect - Previous page displayed for a second while loading a new page in the same tab

Categories

(Firefox for Metro Graveyard :: Browser, defect, P4)

x86
Windows 8.1
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: virgil.dicu, Unassigned)

References

Details

(Whiteboard: feature=defect [preview])

Mozilla/5.0 (Windows NT 6.2; rv:22.0) Gecko/20130328 Firefox/22.0
http://hg.mozilla.org/mozilla-central/rev/962f5293f87f

Haven't found anything similar while searching through bugzilla, so logging.

1. Start Firefox Metro in Windows 8.
2. Visit a page (e.g. mozilla.org)
3. Select the awesomebar.
4. Type the URl of a new page (e.g. bbc.co.uk) and Enter.

Actual result: the page from step 2 is displayed for a second while the page from step 4 is loading.
Blocks: metrov1it5
No longer blocks: metrov1triage
Priority: -- → P1
QA Contact: jbecerra
Summary: Previous page displayed for a second while loading a new page in the same tab → Defect - Previous page displayed for a second while loading a new page in the same tab
Whiteboard: feature=defect c=tbd u=tbd p=tbd
Blocks: 831901
Whiteboard: feature=defect c=tbd u=tbd p=tbd → feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=tbd
On desktop firefox when you have a loaded page on tab and type a new url, it keeps the current page visible for a few seconds until the new page is loaded. 

What I think is happening here is that the start screen shows up with the awesome bar on top of the current page and disappears as soon and you type enter, revealing the old page until the new one is loaded. This is a bit confusing and feels pretty bad for Metro.

I  assume the expected behavior is to show a blank page while the new page is loading - to match what happens when you open a new tab and type an address?
Status: NEW → ASSIGNED
Assignee: nobody → rsilveira
Hi Asa, see question from Rodrigo Comment 1.
Flags: needinfo?(asa)
Hi Rodrigo, point value required.
Flags: needinfo?(rsilveira)
Blocks: metrov1planning
No longer blocks: metrov1it5
Jimm brought up today that this bug should be reconsidered since it's more like a polish detail. Also if we go with the about:blank route, it could affect our page load times.
Flags: needinfo?(rsilveira)
Blocks: metrov1defect&change
No longer blocks: metrov1planning
Assignee: rsilveira → nobody
We also have a new nav bar coming with a brighter progress meter, which should alleviate this quite a bit.
OS: Windows 8 → Windows 8 Metro
Priority: P1 → --
Yes, we need to do something about this. I thought we had a plan in another bug. Maybe one of you all know?
Flags: needinfo?(asa)
(In reply to Rodrigo Silveira [:rsilveira] from comment #1)

(In reply to Asa Dotzler [:asa] from comment #7)
> Yes, we need to do something about this. I thought we had a plan in another
> bug. Maybe one of you all know?

What Rodrigo wrote in comment 1 is correct.

I don't have a plan for fixing this bug without other side effects, but our (Stephen, Yuan, and me) latest plan for changes to the Metro UI will fix this bug as a side effect. The specific part of the plan that fixes it is: Making the URL bar while viewing a tab not bring up the start screen (which is a rather jarring context switch) but rather keep the URL bar in place while displaying the autocomplete results in a translucent (opacity ~90%) "panel" overlaying the content area.
This will be fixed when the story bug at 831910
Blocks: 831910
No longer blocks: metrov1defect&change, 831901
Priority: -- → P4
Whiteboard: feature=defect c=firefox_app_bar_and_autocomplete u=metro_firefox_user p=tbd → feature=defect
Status: ASSIGNED → NEW
Whiteboard: feature=defect → feature=defect [preview]
resolved with half-height autocomplete
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.