User Agent: Mozilla/5.0 (Windows NT 6.0; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release) Build ID: 20140605174243 Steps to reproduce: Type new URL or search in the address bar and hit enter or submit Actual results: Page title or URL in the address bar changes back to the name of the previous page while the progress bar expands, making it appear as if the previous page is reloading. This causes particular confusion and frustration on a slow internet connection. Considering Mozilla's focus on emerging economies, where connection speeds are slower, this might be a greater priority than users in the U.S. and Western Europe might lead you to believe. As a result of this confusion, users may attempt to retype the URL or search query desired, wasting time while that same new desired page reloads again. Or time may be wasted using the back and forward buttons, all of which will cause the name of a previous page (not the actual page requested) to appear in the address bar while the progress bar expands. Expected results: The name of the new URL, search, or page title should remain in the address bar so I know precisely which page is actually loading.
I can reproduce this. I am currently on the addons.mozilla.org, I tap the URL bar and choose a page from the Top Sites list (for example facebook.com). The first page is displayed with the progress bar loading and after that, the facebook page is loaded. Setting the bug to NEW.
filter on [mass-p5]
I started looking into this, and it seems like the root issue here is that we don't update the URL until we get a location change event from gecko. Fortunately, the logic to update the toolbar display is mostly consolidated in ToolbarDisplayLayout#updateFromTab, but that requires that we receive some notification from a tab about the location changing. Two exceptions to this are where manually set the title after receiving an intent and after committing the toolbar edit mode: http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/BrowserApp.java#720 http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/toolbar/BrowserToolbar.java#811 One option here could be to always update the tab location in Tabs#loadUrl, but I'm worried that could have a range of other side effects. In both these cases where we update the display immediately, we're updating the title display only, not the state of the tab. Maybe the tab should just have some sort of location display property that we can update? It would be nice to consolidate this logic on the tab, rather than having one-off places where we update the toolbar directly. mcomella, you've been poking around in some of this code recently - have you thought about this issue at all?
Haven't had time for this, but I still think this would be an important polish bug to fix.
This is outside my current context and realistically, I'm not going to get to it if it doesn't get prioritized. Let's throw it back to triage.
I dont see it on my 6P (nightly today). Kevin, do you see it?
It is better. I still see it using the comment 1 which is tap into the address bar > select a top site we briefly show the old site before switching to the new site.