1240217 - In some cases Enter key doesn't work in Urlbar, and random pages load during typing (100% str)

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160114060719
STR:
1. Copy string "http://example.org/" without quotes
2. Open new tab, paste copied string in Urlbar   [Urlbar now displays "Visit http://example.org/"]
3. Press Ctrl+A   [make sure that suggestions are still displayed]
4. Press Ctrl+V to paste the string again   [make sure that suggestions are still displayed]
5. Press Enter
6. Press Ctrl+T to open a new tab
7. Type "a" in Urlbar

Result:       
 After Step 5 nothing happens
 After Step 7 browser loads the page with search results for "a"

Expectations: 
 After Step 5 http://example.org/ should load in the tab
 After Step 7 Urlbar should display "a". Tab location shouldn't change (page about:newtab should stay)

Comment 1

[Rimas Kudelis [use needinfo to ping]]

This is easily reproducible on Firefox 45.0b5.

Comment 2

[Rimas Kudelis [use needinfo to ping]]

[Tracking Requested - why for this release]:

Comment 3

[[:philipp]]

seems to be happening only with unified autocomplete on....

Comment 4

[Sylvestre Ledru [:Sylvestre]]

Marco, could you take care of that?
Tracking for 45 as it is an user facing regression.

Comment 5

[Marco Bonardo [:mak]]

honestly the steps to reproduce look so unlikely in real life that I'm not sure it's worth prioritizing this vs other work that hits far more commonly, why should a user normally copy and paste the same content twice to the locationbar?

I'm pretty sure step 7 is due to the fact we cache the Enter key sometimes, when we are waiting for results to arrive.
I'm adding this to the triage for the team, but I'm not sure it's a P1.

Comment 6

[Rimas Kudelis [use needinfo to ping]]

(In reply to Marco Bonardo [::mak] from comment #5)
> honestly the steps to reproduce look so unlikely in real life that I'm not
> sure it's worth prioritizing this vs other work that hits far more commonly,
> why should a user normally copy and paste the same content twice to the
> locationbar?
> 
> I'm pretty sure step 7 is due to the fact we cache the Enter key sometimes,
> when we are waiting for results to arrive.
> I'm adding this to the triage for the team, but I'm not sure it's a P1.

These steps might seem unlikely but it could be that these are not the only steps to reproduce it, but these are 100% reproducible, which is very good by itself. I have no idea how the original reporter managed to pin them, but the fact that he did suggests that at least some people might be prone to doing these unlikely things. :)

Comment 7

[Marco Bonardo [:mak]]

I have some ideas of where the bug may lay, and if I'm right it's unlikely to be hit unless you try to fool the urlbar. We have special code when the urlbar value doesn't change across searches, and special code to handle enter, this is likely a mix of those 2 in an edge case.
I appreciate fuzzy testing and it's nice to have these bugs filed, but unless things are common I don't think we have enough resources to fix everything immediately.

Comment 8

[Rimas Kudelis [use needinfo to ping]]

I've been hit by this bug numerous times while just using the browser. I don't think that qualifies as fuzzy testing, does it?

I initially thought that I might be accidentally touching my touchpad, or something like that, or that my system is at fault, but then I thought "hey, this only occurs in Firefox!", and decided to search Bugzilla, and that's how I found this bug. So, at least for me, this issue is common. I can't say with certainty that it will be common for many people though.

Comment 9

[arni2033]

> (comment 5) why should a user normally copy and paste the same content twice to the locationbar?
Because he uses the browser? See below. It can also happen accidentally. Look, you should just put a huge notification "don't put it so hard" on all this brand new stuff (urlbar, searchbar).
> the steps to reproduce look so unlikely in real life
Indeed, because I simplified for better reproducing. You didn't liked long STR in my other report.

You can add Step 2.5: "Switch between suggestions, i.e. press Down once, then Up once".

Step 3 + Step 4 is what I do to replace urlbar value with the string in clipboard when I don't even care what string is displayed in urlbar (reasonable enough).


If you want me to find more "bad" STR (isn't comment 0 "bad" enough?) then:
STR_2 (AR is the same. ER is obvious):
1. Copy string "abc" without quotes
2. Open new tab, _type_ "abc" in Urlbar. Delete selected autocomplete portion if necessary.
     [Urlbar now displays "abc - search with Google"]
3. Press Ctrl+A   [make sure that suggestions are still displayed]
4. Press Ctrl+V to paste the string   [make sure that suggestions are still displayed]
5. Press Enter
6. Press Ctrl+T to open a new tab
7. Type "a" in Urlbar

Note: In Step 4 I imply that user doesn't necessarily always remember contents of clipboard but
      can remember context, e.g. "clipboard contains a very interesting search request"


> (comment 6) how the original reporter managed to pin them
I experienced that many times, probably with different scenarios, and at last detected the exact STR. With all respect, _sometimes_ I feel like the first person to use the browser.

> (comment 7) unless things are common I don't think we have enough resources
This argument is very confusing, since there were enough resources to push new widgets (urlbar, searchbar) with numerous regressions (+ intentional ones) to Release.

Comment 10

[Marco Bonardo [:mak]]

Please let's stay on track and avoid personal attacks. You must understand we don't have infinite money nor infinite developers, and there's A LOT to do, so prioritization must be integral part of the process. And that's why we need to ask questions about everything filed.

What I was saying is that I don't think it's really common to paste in the urlbar the same string that is already typed there AND also selected. All the steps seem to involve that, is that not the case?

Plus there's no proof what Rimas is hitting is the same bug, it seem to have the same outcome, but unless he can notice which steps bring him to the same result, it's hard to tell.

So in the end, I don't have enough information to tell if this is critical or not, based on what's in the bug it doesn't seem to be. If Rimas can help by figuring his steps to reproduce, or you find steps not involving pasting the same text that is already in the urlbar, then it would help.

Comment 11

[arni2033]

comment 9:   s/don't put it so hard/don't push it so hard/

> (comment 10) find steps not involving pasting the same text that is already in the urlbar
I just made that using bug 1221354.  ("chain bugs", see?)
But again, it's completely normal to paste a string that is already in urlbar:
1) In all scenarios I had in mind that user shouldn't be forced to compare clipboard with urlbar
 value. User only remembers the context of copied string (if I understand my own actions correctly)
2) STR_1 may look strange, because url is pasted twice. But again, I mentioned "Step 2.5". Urlbar
 changes its value when I switch between suggestions, even if I switch back to the 1st suggestion.
 So I still think that Step_3+Step_4 are the most reliable way to simply paste the string untouched


I only write this comment to sum up my reasons to think that pasting the same string is OK. I don't
expect any feedback. Plus here's the last scenario (for the record), which only requires one Ctrl+V

STR_3 (AR is the same, ER is obvious):
1. Copy string "https://example.org" without quotes
2. Open https://example.org in a new tab. Make sure that there's no slash after "org"
   Press Ctrl+L, then Down to show urlbar suggestions
3. Press Ctrl+A
4. Press Ctrl+V to paste the string
5. Press Enter
6. Press Ctrl+T to open a new tab
7. Type "a" in Urlbar

Comment 12

[arni2033]

(In reply to Marco Bonardo [::mak] from comment #10)
> or you find steps not involving pasting the same text that is already in the urlbar

STR_4 (from bug 1251016):
1. Copy string "Unique20160224225651" without quotes to clipboard
2. Launch new profile
3. Type(!) "quizlet.com" without quotes in urlbar, press Enter. Close tab with http://quizlet.com/
4. Open new window. Open new tab.
5. Type "q" in urlbar   [autofill will add "uizlet.com/"]
6. Select all text in urlbar (Ctrl+A), paste the string copied in Step 1
7. Press Ctrl+Z 3 times
8. Press Ctrl+Y 3 times
9. Press Enter
10. Press Ctrl+T to open a new tab
11. Type "a" in Urlbar

Comment 13

[Marco Bonardo [:mak]]

I appreciate your effort and passion in bringing on your point, but those steps are still something 99% of users are unlikely to do... So why should we work on this bug rather than (just an example out of my head) working on bug 1209027 that would benefit 100% of our users?

Please don't take this personally, with our limited resources we cannot prioritize this more than other bugs that would help most users.

Comment 14

[Panos Astithas (he/him) [:past] (please ni?)]

Can we get some help figuring out what patch broke this? If it turns up to be a simple fix, we could consider doing it sooner rather than later.

Comment 15

[arni2033]

(In reply to Marco Bonardo [::mak] from comment #13)
> I appreciate your effort and passion in bringing on your point, but those
> steps are still something 99% of users are unlikely to do...
Oh, I see. You looked at the number of steps. I write reliable STR after bug 770773. Here's normal STR

STR_5:
1. Type "bugz"
2. Press Ctrl+Z     <- not necessary step
3. Hold Ctrl+Y for 1s
4. Press Enter.

Voila. The bug. Ctrl+Y can easily be pressed several times to ensure that it's the last typed string
If you skipped STR_5 step 2, it's enough to press Ctrl+Y twice.  
Comment 12 actually shows the case when user expects to press it exactly 3 times.
That's not an "effort" from my side, not in this bug. My only point is that I encounter this urlbar
bug as well as ~50 of other urlbar bugs along, and you want me to. It couldn't be more clear.

> why should we work on this bug rather than bug 1209027 that would benefit 100% of our users?
I always can logically explain my opinion.
1) Because "improvements" always leave us with hundreds of real bugs like this one. Remember
   "omit http://" regresion? It's causing bugs now even with browser.urlbar.trimURLs -> false.
2) If each bug affects 1% of users, then 100% of them are affected by 100 bugs. Well if it's
   independent distribution, it's rather 1-0.99^100 = 63% of users are affected by at least 1 bug.
3) Another answer is that 100% of users are not affected. They don't feel any pain of using the
   browser, so all such work should instead have lower priority. Also, if "average joe" waits
   1s instead of 0.5s or spends 10% CPU instead of 5%, he won't notice if you improve it.
4) Nobody's working on real bugs like bug 1209027, bug 626279 ( <- affects everybody who uses Sync)

> Please don't take this personally, with our limited resources we cannot
> prioritize this more than other bugs that would help most users.
If you knew there were lots of work in bug 1209027& Co, you wouldn't push breakages to Release
unless you came up with this excuse in advance.  
It looks as if you wanted as many regressions in urlbar as possible, when I read bug 1251386
That regression was marked WONTFIX, so you don't even want _anybody_ to fix it.

Comment 16

[arni2033]

The nature of this bug is that everybody can encounter it accidentally during text editing, just like me. I can't control the way I'm editing text, and I never relied on those STR specifically. But I often see this, so I tracked down some STR (because bugs w/o STR will stay untouched for sure)

Regression from bug 1105967 (tested with unifiedcomplete pref enabled).
I saw the same AR in bug 1187747, but it was magically fixed by bug 1054914. Maybe it is a clue.
>   https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=368c62292249&tochange=07c04d7a483a
If _I_ reported 1105967, it'd probably be abandoned right away, because only 1% affected

Comment 17

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160407164938

This is still reproducible on the latest FF release (45.0.2) and on the latest Nightly build (20160412050029).

Comment 18

[arni2033]

> (comment 10) find steps not involving pasting the same text that is already in the urlbar
>>>   My Info:   Win7_64, Nightly 50, 32bit, ID 20160702030219
STR_6:
1. Open url [1], select all text on the page, copy the generated url to clipboard
2. Open new tab, focus urlbar, hold Ctrl key
3. As fast as possible press V, then Enter, then K (to paste url, then visit it, then focus searchbar)
4. Open new tab, type "=" in urlbar
 (repeat)
5. If you haven't reproduced the bug, go to Step 1 (don't open the page again, just reload it)

AR:  Step 3 - the url isn't loaded.         Step 4 - page with search results in Google for "=" loads
ER:  Step 3 - browser should load the url.  Step 4 - browser should show suggestions for "="

> [1] data:text/html,<body><script>var D = (""+Date.now()).replace(/\d/ig,function(d){return "abcdefghij".substr(+d,1)});document.body.innerHTML="https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange="+D+"&tochange="+D;</script>

Note:
1) This deserves a commentary. Step 3 is usually "press Ctrl+V, then Enter, then Ctrl+T" for me. The
   point is that urlbar suggestions should be hidden after Enter, but before suggestions are updated
  (well, you know, the obvious fact: urlbar suggestions are very laggy [it takes long time for them
   to update from previous state to new one]). In this way, url pasted in Step 3 won't be visited.
2) This also happens when autocomplete suggestions are so laggy they don't even appear when I type
3) I can easily reproduce this on my test profile w/ 17055 items in library. Obviously, on a normal
   profile, that always has 104000 items in library, it's also easily reproducible. However, knowing
   the fact that Firefox developers always use the best PCs available to avoid numerous Firefox bugs,
   I came up with a method that allows to reproduce it even on clear profile (well, when I just create
   a new profile, it's very laggy, so it's easily reproducible anyway). It's AutoHotkey shortcut that
   performs Step 3 for you when you press Insert key. Install AutoHotkey, create and launch script:

#Persistent
return

Insert::
send +{Insert}
send {Enter}
send ^k
return


>>>   My Info:   Win7_64, Nightly 50, 32bit, ID 20160702030219
STR_7:  (classic)
1. Open bug 1240218, make sure that url if fully visible in urlbar
2. Select "8" in url using mouse, type "9"
3. Select "9" in url using mouse, type "9"
4. Press Enter
5. Open new tab and type "="

AR:  Page with search results in Google for "=" opens in Step 5
ER:  Bug 1240219 should open in Step 4. Suggestions should appear in Step 5

Comment 21

[arni2033]

STR_6 (75% reproducible) is regression from bug 1266375. Regression range:
> https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=6bbcf33e1a709cc6bd9a9ab73e303093fc748239&tochange=597390d44c49cb5c89260feb4f5e1e6ef2eef15c

Probably it's a good idea to finally fix this bug instead of just making it worse? (e.g in bug1266375)

Comment 22

[arni2033]

And also, I have to add for Marko Bonardo:
Marco, with the wave of reports coming with 48's release (each of them fails to reliably reproduce this issue, unlike this bug report, doesn't mention underlying bug, unlike this report, doesn't have regression range unlike this report), can you re-evaluate the seriousness of this bug/problem? Thanks.

Comment 24

[Marco Bonardo [:mak]]

We should first look at Enter behavior in Bug 1279864, and when that is "fixed" we can re-evaluate these other related bugs.

Comment 26

[Marco Bonardo [:mak]]

I think most if not all of the issues here have been fixed up to Firefox 50 beta4.
Could you please check and let us know if any of the above STR are still reproducing the problem?

Comment 27

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I reproduced these issues (from STR to STR_7)  using Fx 46.0a1, build ID: 20160115055328, on Windows 10 x64.
I can confirm these issues are fixed, I double checked all 7 cases with STR using: 

 -Windows 10 x64
 -Mac OS X 10.11.6
 -Ubuntu 14.04 LTS

I verified on:

 - Fx 50.0b6 (20161010144024)
 - Fx 51.0a2 (20161011004015)
 - Fx 52.0a1 (20161011030212)

Cheers!

Comment 28

[arni2033]

(In reply to Cristian Comorasu from comment #27)
> I can confirm these issues are fixed, I double checked all 7 cases with STR using: 
(I'm answering to the whole your comment)
One thing about testing I always check: you can't be 100% sure that bug is fixed unless you reproduced
it on reported version using provided STR (i.e. that you do exactly what reporter did).
Sorry if you have already taken this into consideration.
Anyway, thanks for testing all 7 cases (still I'd prefer if Marco himself finally tested some instead
of asking me why I need to paste strings into urlbar, intentionally keeping thsi bug for ~2 years etc)

>>>   My Info:   Win7_64, Nightly 52, 32bit, ID 20161011030212 (2016-10-11)
My results are different (on clear profile):

STR_1:   Fixed
STR_2:   Fixed
STR_3:   Fixed
STR_4:   Fixed
STR_5:   Fixed
STR_6:   NOT FIXED
STR_7:   Fixed
STR_8:   Fixed

I just encountered STR_6 when pasted a url, but reliable way to reproduce is mentioned in comment 18

STR_8:
1. Open url [2], select all text on the page, copy the generated url to clipboard
2. Open new tab, type "a" in urlbar, wait until suggestions appear
3. Open new tab, focus urlbar, hold Ctrl key
4. Press V, then as fast as possible click on selected tab (to hide suggestions). Release Ctrl key
5. Press Enter
6. Open new tab, type "=" in urlbar
 (repeat)
7. If you haven't reproduced the bug, go to Step 1 (don't open the page again, just reload it)

AR:  Step 5 - the url isn't loaded.         Step 6 - page with search results in Google for "=" loads
ER:  Step 5 - browser should load the url.  Step 6 - browser should show suggestions for "="

> [2] data:text/html,<body><script>var D = (""+Date.now()).replace(/\d/ig,function(d){return "abcdefghij".substr(+d,1)});document.body.innerHTML="https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange="+D+"&tochange="+D;</script>

Comment 29

[Marco Bonardo [:mak]]

(In reply to arni2033 from comment #28)
> Anyway, thanks for testing all 7 cases (still I'd prefer if Marco himself
> finally tested some instead
> of asking me why I need to paste strings into urlbar, intentionally keeping
> thsi bug for ~2 years etc)

This bug is open from January and unified complete has been enabled in Firefox 48, released in August. The fix will be in Firefox 50 (November release I think). That doesn't sound too bad to me, especially considered how complex some of these issues were.
FYI I actually had to go through all of your STR, since that is my job, as you noticed 7 out of 8 have been fixed. The remaining one appears to be quite complex and may have slipped through the cracks, Since the others are fixed, looks like that bug has a different root cause, and thus should be moved to a separate report. The bugzilla rules ideally want one bug per report, not cause we are mad, but because otherwise tracking where things are fixed becomes a nightmare.

So, we will consider this bug fixed cause it fixed one of the root causes of your issues, that way we can track it properly. The QE on those STR is complete.
Please move the remaining issue to a new bug that we can track and fix apart. Thank you for your cooperation.