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.

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.

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.

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.

Soft blocker nom?

Looks like bug 797075 was sufficient to fix this problem.

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

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

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

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?

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.

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

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.

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.

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

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