1249330 - Selected URL disappears when tab changed

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

[RTK]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160209234642

Steps to reproduce:

* Open a new blank tab;
* Type part of some previously visited website;
* Select it with arrow keys (don't click it);
* Click outside the URL bar to hide the dropdown menu;
* Now you can see the entire URL in the bar, you can click on the bar and then out of the bar many times, the full URL remains there;
* Now select another previously opened tab or a new one;
* Return to the original tab, you can see the URL turned what you have typed, not what you have selected;


Actual results:

The original selected URL becomes what you have typed instead of what you have selected


Expected results:

The URL should remains as the one you have selected

Comment 1

[Loic]

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=be4ba3d5ca9a&tochange=74edfbf0e6a3

Marco Bonardo — Bug 1083469 - Allow to use old keywords APIs along with Bookmarks.jsm r=mano

Comment 2

[Loic]

Marco, is it the normal behaviour after bug 1083469?

Comment 3

[Marco Bonardo [:mak]]

I have no idea of the relation with bug 1083469, based on the touched code it should not have any effect on the persistence in the urlbar.
That said, I think both behaviors (expected and actual) have some advantages and disadvantages. Off-hand I prefer the new behavior, cause when you leave the tab you are supposed to be "done" with a task, so it makes sense to revert to a clean state, since nothing has been confirmed.
Globally it's an edge case with uninteresting gains regardless how we fix it, and thus it's likely not worth a fix.

Comment 4

[RTK]

I accept your point of view, but I cannot see any advantage of the new behaviour, since I had rolled down till the site I have selected with arrow key, and for some reason I needed check another tab, when I come back it has vanished, I believe if I spent time to choose the site, I would like it to remain as the one I had picked, otherwise I could have not selected with arrow keys.

Comment 5

[RTK]

(In reply to Marco Bonardo [::mak] from comment #3)
> I have no idea of the relation with bug 1083469, based on the touched code
> it should not have any effect on the persistence in the urlbar.
> That said, I think both behaviors (expected and actual) have some advantages
> and disadvantages. Off-hand I prefer the new behavior, cause when you leave
> the tab you are supposed to be "done" with a task, so it makes sense to
> revert to a clean state, since nothing has been confirmed.
> Globally it's an edge case with uninteresting gains regardless how we fix
> it, and thus it's likely not worth a fix.

Said that from comment #4, for instance: you have in historic the site http://sample.com/show-product/123 that you had accessed some while before, and you have your webmail at another tab, where someone is telling you to check some product ids, the person didn't send you the full url, only ids, in the current behaviour you would have to enter the full url or you would have to visit the wrong id just for persist the url on the bar, can you see the trouble?
Ok, you could have copied before opening a new tab, but if it is several ids, it will be tiring to open one at a time, I would rather to open several tabs before, then passing through them changing only the ids.

Comment 6

[Marco Bonardo [:mak]]

I'm sorry, I understand your use-case, but it's surely a little bit exotic and edge case.

If you end up doing that often you could write a tiny (less than 50 rows of javascript) restartless add-on that takes a csv list of ids and opens tabs with a base address.

Even simpler, without going fancy, just create a bookmark keyword for the url like
http://myurl/products/%s, assign a keyword like "p", then open a tab and just type "p 33[ENTER]"...

We have lots of bugs, much worse than this, that means the likely time for edge cases like this to be resolved is years. Not sure it's worth waiting so long, since there are alternative solutions.

Comment 7

[RTK]

(In reply to Marco Bonardo [::mak] from comment #6)
> I'm sorry, I understand your use-case, but it's surely a little bit exotic
> and edge case.
> 
> If you end up doing that often you could write a tiny (less than 50 rows of
> javascript) restartless add-on that takes a csv list of ids and opens tabs
> with a base address.
> 
> Even simpler, without going fancy, just create a bookmark keyword for the
> url like
> http://myurl/products/%s, assign a keyword like "p", then open a tab and
> just type "p 33[ENTER]"...
> 
> We have lots of bugs, much worse than this, that means the likely time for
> edge cases like this to be resolved is years. Not sure it's worth waiting so
> long, since there are alternative solutions.

I see, for us it can be easily solved in many ways, and there are more important issues than this minor one. I apologize for taking your time, if I see a less trivial issue in near future I'd be glad in helping.

Comment 9

[arni2033]

I do this about 50 times per day. There's no way somebody can tolerate this behavior of Location bar

Suggested workaround "write an extension" doesn't work for me, because there're hundreds of Location
bar breakages that I encounter, and their number will only grow if you'll keep ignoring regressions.