The default bug view has changed. See this FAQ.

After opening a new tab, old tab is briefly seen

VERIFIED FIXED in Firefox 21

Status

()

Firefox for Android
General
P3
normal
VERIFIED FIXED
5 years ago
8 months ago

People

(Reporter: Martijn Wargers (dead), Assigned: bnicholson)

Tracking

({polish})

Trunk
Firefox 19
ARM
Android
polish
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox11 affected, firefox12 affected, firefox21 verified, blocking-fennec1.0 -, fennec11+)

Details

(Whiteboard: startup-ux, tabs-ux, ui-responsiveness)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Steps to reproduce:
- Open a new tab, by tapping on the "+"-sign in the tab list popup.
- Choose one of the autocomplete entries.

Expected result:
- The new tab is immediately shown with the chosen url that gets loaded.

Acctual result:
- For a brief moment, the old tab is shown, then the new tab gets opened with the chosen url that gets loaded.

Comment 1

5 years ago
It looks like this is because we're waiting for the Tab:Added message to get back to us from Gecko before calling handleSelectTab, which changes the tab in the Java UI. I guess we need to have information about the tab from Gecko to update the UI properly, but maybe we can cheat and make a stub new tab that gets populated after the fact.

The same thing is true of switching tabs - we do a message passing round trip to Gecko and back before updating the Java UI.
Assignee: nobody → margaret.leibovic

Updated

5 years ago
Assignee: margaret.leibovic → nobody

Updated

5 years ago
status-firefox11: --- → affected
status-firefox12: --- → affected

Updated

5 years ago
Depends on: 720494

Comment 2

5 years ago
margaret, over to you since you know more about this than most.  if you think there is a better person to own this, please reassign.
Assignee: nobody → margaret.leibovic
tracking-fennec: --- → 11+
Keywords: polish
Priority: -- → P3

Comment 3

5 years ago
I was looking into doing the same thing to the Tab:Add(ed) messages that I did with Tab:Close(ed) and Tab:Select(ed), but it's more complicated since we're actually using parameters we get back from Gecko when we open the new tab. However, we don't need to wait on Gecko to know that we need a new tab in the UI, and we know the new URL, so we could at least update BrowserToolbar immediately and continue to update it in with more data as we get it.

Updated

5 years ago
Blocks: 721008

Updated

5 years ago
Whiteboard: startup-ux

Updated

5 years ago
Whiteboard: startup-ux → startup-ux, tabs-ux
Soft blocker nom?
blocking-fennec1.0: --- → ?
blocking-fennec1.0: ? → -
(Assignee)

Updated

5 years ago
Depends on: 797075

Updated

5 years ago
Whiteboard: startup-ux, tabs-ux → startup-ux, tabs-ux, ui-responsiveness

Updated

5 years ago
Assignee: margaret.leibovic → nobody
(Assignee)

Comment 5

5 years ago
Looks like bug 797075 was sufficient to fix this problem.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
I can reproduce this issue on the latest Nightly even if bug 797075 has already landed. Which bug should be reopened?

--
Firefox 19.0a1 (2012-10-15)
Device: Galaxy Note
OS: Android 4.0.4
(Assignee)

Comment 7

5 years ago
(In reply to Cristian Nicolae (:xti) from comment #6)
> I can reproduce this issue on the latest Nightly even if bug 797075 has
> already landed. Which bug should be reopened?
> 
> --
> Firefox 19.0a1 (2012-10-15)
> Device: Galaxy Note
> OS: Android 4.0.4

Depending on what is meant by seeing the "old tab", there are actually two parts to this bug:
1) the URL bar/throbber is not updated immediately, and
2) the actual drawn page is not updated immediately

Bug 797075 should have fixed the first issue. The second issue (which wouldn't have been fixed) is more complicated because the LayerView won't be updated until Gecko draws to it - so stubbing tabs can't help here. Is this the problem you're talking about?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Brian Nicholson (:bnicholson) from comment #7)
> (In reply to Cristian Nicolae (:xti) from comment #6)
> 
> Depending on what is meant by seeing the "old tab", there are actually two
> parts to this bug:
> 1) the URL bar/throbber is not updated immediately, and
> 2) the actual drawn page is not updated immediately
> 
> Bug 797075 should have fixed the first issue. The second issue (which
> wouldn't have been fixed) is more complicated because the LayerView won't be
> updated until Gecko draws to it - so stubbing tabs can't help here. Is this
> the problem you're talking about?

It seems that only the 2nd part of this issue is still reproducible. The first one is fixed indeed.
(Assignee)

Comment 9

5 years ago
Fixing this part will be more complicated. We'd likely have to resort to setting a background color on the LayerView, then clearing the background color after a draw for new tabs (similar to bug 799617).
(In reply to Brian Nicholson (:bnicholson) from comment #9)
> Fixing this part will be more complicated. We'd likely have to resort to
> setting a background color on the LayerView, then clearing the background
> color after a draw for new tabs (similar to bug 799617).

Is it possible to draw a temporary background with the Firefox logo, like it happens on about:home for those websites which don't have a thumbnail saved?
(Assignee)

Comment 11

5 years ago
I guess we'd need UX to weigh in here. I think a white background might make sense because it makes the page feel like it's loading immediately. Also, on desktop Firefox, opening a URL in a new tab (ctrl+shift clicking on a link) shows all white before the page is drawn.
You're right. I was thinking about that logo just to make a nice difference between desktop and Firefox for Android, but the sensation would be that even if the page is loading, nothing happens.
(Assignee)

Comment 13

5 years ago
Created attachment 672548 [details] [diff] [review]
Part 1: Only send SELECTED tab event if the tab has changed

Without this change, selecting the tab that is already selected causes the LayerView color to change without getting cleared (since a draw isn't retriggered).
Assignee: nobody → bnicholson
Status: REOPENED → ASSIGNED
Attachment #672548 - Flags: review?(mark.finkle)
(Assignee)

Comment 14

5 years ago
Created attachment 672569 [details] [diff] [review]
Part 2: Clear background color when selected tab changes

This builds upon bug 799617 to clear the LayerView every time a tab is selected.

Since there's some delay between selecting the tab and drawing its contents, this causes just the background to be shown for a short period when a tab is selected. This is better to some extent because the view is instantly updated when the user switches tabs, but it also feels weird to show another state during the process. That is: before, it showed the old page with a bit of delay after switching tabs. Now, it shows the old page, then the background immediately after switching tabs, then the tab content.
Attachment #672569 - Flags: review?(bugmail.mozilla)
Comment on attachment 672569 [details] [diff] [review]
Part 2: Clear background color when selected tab changes

Review of attachment 672569 [details] [diff] [review]:
-----------------------------------------------------------------

The only hiccup I see here is that LayerRenderer.onTabChanged gets run on the UI? thread whereas the other pieces of code that touch the paint state run on the compositor thread. I can't think of any interleaving that would actually cause problems though. Maybe just add a comment in onTabChanged so if we end up with strange behaviour later we can check to see if that's causing it.
Attachment #672569 - Flags: review?(bugmail.mozilla) → review+
Attachment #672548 - Flags: review?(mark.finkle) → review+
(Assignee)

Comment 16

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/8ab0fa553069
http://hg.mozilla.org/integration/mozilla-inbound/rev/77ac649ce11b
https://hg.mozilla.org/mozilla-central/rev/8ab0fa553069
https://hg.mozilla.org/mozilla-central/rev/77ac649ce11b
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19
(Assignee)

Updated

5 years ago
Blocks: 740335
(Assignee)

Updated

5 years ago
Depends on: 803374
This issue is not reproducible on the latest Nightly. Closing bug as verified fixed on:

Firefox for Android
Version: 21.0a1 (2013-01-29)
Device: Galaxy R
OS: Android 2.3.4
Status: RESOLVED → VERIFIED
status-firefox21: --- → verified
You need to log in before you can comment on or make changes to this bug.