1574257 - WIth long URL part of URL in address bar is not visible

Status: RESOLVED DUPLICATE of bug 1496158

(Firefox :: Address Bar, defect, P3)

Description

[Sören Hentzschel]

Attachment: screenshot

STR:

1. open a page with a long URL, for example https://bugzilla.mozilla.org/buglist.cgi?list_id=14852764&resolution=---&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
2. scroll to the right

Actual:

Part of the URL is not visible, please see the attached screenshot.

Expected:

No hidden characters.

Seems to be an older regression. The tool mozregression pointed me to https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6a320851d377068d46a59ff11d5d5124b219138a&tochange=f6df6a982ee9510ca32dd3afa52dfe9f8c3586a3 but mozregression was not able to bisect further.

Tested on macOS 10.15 Beta 4.

Comment 1

[Sören Hentzschel]

I cannot reproduce on another system with macOS 10.11, so maybe Catalina related.

Comment 2

[Sören Hentzschel]

The issue is still there with Catalina Beta 6.

Comment 3

[Haik Aftandilian [:haik]]

I am not able to reproduce this on Nightly (2019-08-22) running on Catalina Beta 6 (19A536g). I'm using US English locales.

Comment 4

[Sören Hentzschel]

Attachment: screencast

I made a screencast to demonstrate the problem.

As you can see this always happens when you scroll all the way to the right. The "textoverflow" attribute of #urlbar always changes from "end" to "start" when this happens.

It seems to be that is has something to do with this change:
https://hg.mozilla.org/mozilla-central/rev/b6233f4d899c3da8143461b19201baf69e63595f

But the Bugzilla ticket is not public so it's only a guess.

I'll ni? the patch author and reviewer because so far no one has been able to reproduce the issue. Do any of you have any ideas? It only happens on my machine with macOS Catalina Beta 4/6 but not on another machine with macOS 10.11 and it also happens with a new Firefox profile.

Comment 5

[Drew Willcoxon :adw]

This is the expected behavior, I think?

Comment 6

[Sören Hentzschel]

(In reply to Drew Willcoxon :adw from comment #5)

This is the expected behavior, I think?

This is very unlikely - why should the protocol be visible if you scroll all the way to the right but not if you scroll only a bit to to the right? And why should there be so much empty space? And as expected beheviour it should be reproducible on every system, right? Neither I can reproduce on another system nor :haik was able to reproduce.

Comment 7

[:Gijs (he/him)]

Reverting the priority because if this was expected, it should be marked invalid. I don't think it is expected.

I think this is pretty similar to bug 1496158; The correct behaviour effect should be applied sooner, and should show the domain as well. The current behaviour is the result of attempts to force-show the protocol and domain, and the fact that we don't actually do anything about scrolling the URL bar, which is... an unusual thing to do. It only happens on mac, on Windows it takes shift+scrollwheel to scroll inputboxes (which is even more niche).

I expect scrolling to the end triggers some but not all the event listeners that are "normally" involved to trip the current behaviour, and/or it might not reset the scroll state where it does reset the selection (ie cursor) - but it's been a while since I looked at it, and it's not immediately obvious to me what the correct behaviour is, without completely breaking scrolling the URL bar. Between this and bug 1496158 we should probably re-evaluate the current state. I'll try and have a look either tomorrow (but I'm not working all of tomorrow so I might not have time) or Tuesday, if Marco doesn't beat me to it.

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

It is expected in the sense we force showing the protocol when the url is completely scrolled to the right, assuming it's because there is an RTL host. This is a case where the url is scrolled but the host is not RTL. We can detect whether the domain is RTL, as I already suggested in bug 1496158.

Comment 9

[:Gijs (he/him)]

This seems to just be a dupe of bug 1496158?