Closed Bug 1496158 Opened 5 years ago Closed 4 years ago

Clicking a URL on the address bar that overflows that URL bar, pressing End and clicking the content area (or horizontally scrolling the input using the mousewheel/trackpad) will apply the fading effect on the URL's host name

Categories

(Firefox :: Address Bar, defect, P3)

Product:
Firefox
Component:
Address Bar
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 71
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- wontfix
firefox63 --- unaffected
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- verified

People

(Reporter: itiel_yn8, Assigned: Gijs)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [fxsearch])

Attachments

(3 files)

Screencast
64.88 KB, image/gif
Details
Screencast with a different STR
496.29 KB, image/gif
Details
Bug 1496158 - only apply start-fade to url bar input if we've force-scrolled to the right because of an RTL domain, r?mak
47 bytes, text/x-phabricator-request
Details | Review 
This is very similar to bug 1489402 and it's regression range is the same.

STR:
1. Open any URL that overflows the URL bar
2. Click the URL bar
3. Press End on the keyboard
4. Click anywhere on the content area

AR:
The host name will have the fading effect on it.

ER:
The fading effect should be applied on the last visible characters of the URL.

See attached screencast.

2018-10-03T20:28:56: DEBUG : Starting merge handling...
2018-10-03T20:28:56: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=621979b26f697513f06f4c5f2db1d5ee580c4363&full=1
2018-10-03T20:28:58: DEBUG : Found commit message:
Bug 1485746 - Cursor gets reset to start of address bar on window switch. r=adw

This restores the previous behavior where we set the selection only when setting a new different value

Differential Revision: https://phabricator.services.mozilla.com/D4528

2018-10-03T20:28:58: DEBUG : Did not find a branch, checking all integration branches
2018-10-03T20:28:58: INFO : The bisection is done.
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox64: --- → affected
Flags: needinfo?(mak77)
Attached image Screencast — 

    
    

    
  
Thank you for the detailed report.
This is less critical, because that url was already shown to you properly. It's mostly an annoyance, not worth tracking for the release.
Flags: needinfo?(mak77)
Priority: -- → P3
Whiteboard: [fxsearch]

    
    

    
  
There's another STR resulting in the same effect:
1. Start typing in the URL bar a URL that already exists in your browser history and that overflows the URL bar
2. With the down arrow key, hightlight that item but don't click Enter
3. Click anywhere on the content area

See attached.

    
    

    
  


  

    
    

    
  
we probably need a further attribute that states whether the host is RTL or not, and then we can apply the css rule more precisely.

    
    

    
  
(In reply to Marco Bonardo [::mak] from comment #6)
> we probably need a further attribute that states whether the host is RTL or
> not, and then we can apply the css rule more precisely.

Why RTL? The screencasts here were taken on RTL Nightly, but this affects also LTR.
See attachment 9020599 [details].

(Unless you're referring to something else?)

    
    

    
  
I said RTL host, the locale directionality doesn't matter.

    
  
Summary: Clicking a URL on the address bar that overflows that URL bar, pressing End and clicking the content area will apply the fading effect on the URL's host name → Clicking a URL on the address bar that overflows that URL bar, pressing End and clicking the content area (or horizontally scrolling the input using the mousewheel/trackpad) will apply the fading effect on the URL's host name

    
    

    
  
See comment 2 for marking it fix-optional.



          status-firefox67:
          affected → fix-optional

    
    

    
  
Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.



          status-firefox68:
          --- → affected

    
    

    
  
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/7d116cd6cec3
only apply start-fade to url bar input if we've force-scrolled to the right because of an RTL domain, r=mak

    
  
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/7d116cd6cec3


Status: ASSIGNED → RESOLVED
Closed: 4 years ago

          status-firefox71:
          --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71

    
    

    
  
This seems to be fixed now, but I'm unable to reproduce the steps from bug 1502402 to verify. Do we need qe+ here?



    
    

    
  
(In reply to Itiel from comment #17)




This seems to be fixed now, but I'm unable to reproduce the steps from bug 1502402 to verify.




Sorry, I don't understand this part. You reported this bug, so presumably when you reported it you could reproduce the problem. Are you saying on nightlies without this change, you can't reproduce the original bug as reported here / in bug 1502402  / in bug 1574257 ?


Flags: needinfo?(itiel_yn8)

    
    

    
  
(In reply to :Gijs (he/him) from comment #18)




(In reply to Itiel from comment #17)




This seems to be fixed now, but I'm unable to reproduce the steps from bug 1502402 to verify.




Sorry, I don't understand this part. You reported this bug, so presumably when you reported it you could reproduce the problem. Are you saying on nightlies without this change, you can't reproduce the original bug as reported here / in bug 1502402  / in bug 1574257 ?




Bug 1502402 mentions "scrolling", but scrolling an overflowed urlbar doesn't seem to be a thing on Windows, presumably? Or maybe a mouse that has a horizonal scroller is required, not sure.


Flags: needinfo?(itiel_yn8)

    
    

    
  
(In reply to Itiel from comment #19)




(In reply to :Gijs (he/him) from comment #18)




(In reply to Itiel from comment #17)




This seems to be fixed now, but I'm unable to reproduce the steps from bug 1502402 to verify.




Sorry, I don't understand this part. You reported this bug, so presumably when you reported it you could reproduce the problem. Are you saying on nightlies without this change, you can't reproduce the original bug as reported here / in bug 1502402  / in bug 1574257 ?




Bug 1502402 mentions "scrolling", but scrolling an overflowed urlbar doesn't seem to be a thing on Windows, presumably? Or maybe a mouse that has a horizonal scroller is required, not sure.




You can scroll input fields with shift+scrollwheel on windows (and, I guess, Linux, but I haven't tried). You don't need the modifier on mac.



    
    

    
  
Ah, okay then, awesome. Good to know, thanks.

So yeah, seems to be fully fixed.


Status: RESOLVED → VERIFIED

          status-firefox71:
          fixed → verified

    
    

    
  
Is this something we should consider for Beta uplift or can it ride Fx71 to release?


Flags: needinfo?(gijskruitbosch+bugs)

    
    

    
  
We've wontfixed for 6 releases and although there's some dupes, so I'm not sure it makes sense to rush it. On the other hand, the change is straightforward enough, though I don't feel we have a particularly great grasp of all the edgecases here. So I'm on the fence. Marco, thoughts?


Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mak77)

    
    

    
  
I'd not rush it, as I said in comment 2 I don't think this is a critical problem, because the host was shown properly at least once, and this happens after an explicit user action.

If anyone posts good reasons to uplift it, then the patch doesn't look scary, so we can surely re-evaluate.


Flags: needinfo?(mak77)

          You need to log in
          before you can comment on or make changes to this bug.