STR: Type "classified.nextval" in location bar Result: Suggestion says "Visit http://classified.nextval/" Expectations: Should be a way to search for that term in default engine It was said in bug 1196906 that Shift key is used to bypass urlbar actions, so it may be used here as well Build ID 20150825030212, Nightly 43

Not sure if this is duplicate of 1059395

This is not duplicate of bug 1080682, just like bug 1256074 (duplicate of this) is not a duplicate of bug 1080682.

since bug 1256074 presents a possible solution, rather than just the problem, I'm duping this there.

(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #5) > since bug 1256074 presents a possible solution, rather than just the > problem, I'm duping this there. This bug was created to decide on solution. It makes no sense for somebody (who is not designer) to "pick one possible solution, ask designer if it's good, then repeat the process". I suggested that designer should create general solution in this bug, therefore this bug makes more sense than bug 1262507. And should block that bug. Also, there is still a question, why you keep ignoring my bugs and filing more duplicates of them.

This bug _also_ presents a possible solution, but it's meaning is not "this solution or nothing else", unlike bug 1262507.

(In reply to arni2033 from comment #6) > Also, there is still a question, why you keep ignoring my bugs and filing > more duplicates of them. We don't ignore your bugs, nor anyone else. But notice that you are messing up with out flags (like the decision to undupe this) and that will make us ignore this bug, cause it's not properly tracked. I'd honestly suggest to have some trust in our job, since we do it from quite some years.

arni2033, I know you mean well, but please stop fighting with the bug handling process. The issue you reported is acknowledged, we thank you for reporting it and we intend to work on it. Which bug will be used to track the work is utterly irrelevant to the importance of your contribution and our appreciation for it.

(In reply to Marco Bonardo [::mak] from comment #8) > But notice that you are messing up with out flags (like the decision to undupe this) > and that will make us ignore this bug, cause it's not properly tracked. I still think that I made the right decision, because original issue was that browser doesn't provide a fast way to search for typed text (see bug in "See also" list which is related to keyword case). Back in the days I was filing 1 specific case per bug report because I had no time to describe all cases and stuff, which wasn't completely right... But this bug was never considered as an issue with one single text in urlbar - "classified.nextval", and nobody ever asked what does reporter expect, etc Anyway, now I need an advice on bug filing. My original issue (that I have to this day) was [*] "There's no fast way to search for text typed in urlbar with default search engine", so if you (team) don't think this report is appropriate to even look at [*], I'll have to close this bug and clone it w/ more detailed cases, which I don't want. However, if you are already 100% sure that [*] is filed somewhere or that [*] is wontfix, I won't need to file any new bugs for the issue. NI for your opinion. Note: oneOffButtons regression added to urlbar suggestions isn't a fast way, as working with mouse right after typing something with both hands, and hitting a ~40px * 40px area on the screen isn't fast > I'd honestly suggest to have some trust in our job, since we do it from quite some years. I really tried not to respond, but this is, in fact, why I am here: it's getting worse through years. (isn't related to this and similar bugs as it is an enhancement bug)

We now have an explicit second entry for searching when you type "classified.nextval". You get the action row stating "visit", followed by a search row for searching "classified.nextval". I think this solves the "quick way to search without having to mouse-over the small button" Also, you can quickly move to the first one-off button using ALT+DOWN combo, so ALT+DOWN and ENTER should do, without having to use the mouse. Thus, we already provide 2 alternative solutions for mouse and keyboard. The only remaining thing we could evaluate is to allow using shift on the action row to override, but I'm not completely sure it would act in a coherent way, in this case it may override visit, but what happens in the search case? we override search and instead try to visit? And if the string is unvisitable (not a uri-like thing)? That sounds like introducing confusing behaviors (and subtle bugs), through an undiscoverable override (the undiscoverable switch to tab override is bad enough). I'd probably wontfix such thing for now, cause, now that we already have solutions in place, its value looks very low compared to its cost.

(In reply to Marco Bonardo [::mak] from comment #11) > We now have an explicit second entry for searching when you type > "classified.nextval". You get the action row stating "visit", followed by a > search row for searching "classified.nextval". > I think this solves the "quick way to search without having to mouse-over > the small button" > Also, you can quickly move to the first one-off button using ALT+DOWN combo, > so ALT+DOWN and ENTER should do, without having to use the mouse. > Thus, we already provide 2 alternative solutions for mouse and keyboard. Based on this I think this is WFM/FIXED or a dupe of the bug where this was implemented.