Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100723 Minefield/4.0b3pre Currently on trunk, one is unable to cursor through local pages that have been previously opened and stored in history through the same tab. STR: 1. Clear all browsing history. 2. Open a local page from disk by typing out the full URL in the location bar. Wait 4 seconds for it to save it history. 3. In the same tab, open a second yet different local page by typing out the full url in the location bar. Wait 4 seconds for it to save to history. 4. Clear the location bar url 5. Try hitting up and down on your keyboard, and or clicking the inverted triangle on the location bar to open the drop-down listing ER: Should see the two previous locally hosted pages in the drop-down AR: No results are found This behaviour works as expected with actual online pages but seems to be a widget issue with local content. This behaviour works as expected in 1.9.2

With step 2 you can also open pages from localhost. All those entries aren't displayed with step 5. Would be great to get a regression range, since no developer could point us to a change in that area. I would assume it's a regression then.

It's a recent regression on trunk which has been started between the builds 10071503 and 10071603. http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c&tochange=96de199027d7 Only bug 571672 comes into my mind here, which could have changed the behavior. Asking for blocking2.0 because don't listing localhost or file urls in the autocomplete when directly pressing the down key is a highly visible regression.

Bug 571672 didn't change what shows up in the autocomplete results, only what happens when you select a result. So I'd be surprised if that's the regression. More likely are deep Places changes; there are a few in that range, bug 556400 and bug 578557 especially.

(In reply to comment #3) > Bug 571672 didn't change what shows up in the autocomplete results, only what > happens when you select a result. So I'd be surprised if that's the > regression. More likely are deep Places changes; there are a few in that > range, bug 556400 and bug 578557 especially. Thanks Drew! Marco or Benjamin, could one of you have a look at it?

Sounds like this is more likely to just be a mozmill timing issue related to us making autocomplete additions async (bug 556400?), rather than something that will actually negatively impact users. Based on that, I don't think we should block on this.

(In reply to comment #5) > Sounds like this is more likely to just be a mozmill timing issue related to us > making autocomplete additions async (bug 556400?), rather than something that > will actually negatively impact users. Based on that, I don't think we should > block on this. Gavin, this is not a Mozmill timing issue. We have discovered it with Mozmill, but see comment 0 and comment 1 for manual steps. Retesting it with a current nightly build WFM. Aaron, can you please also check?

Yeah this WFM now. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101221 Firefox/4.0b9pre