"https" is pushed off left edge of address bar (overlapping buttons!) for long URLs with broken cert configurations

VERIFIED FIXED in Firefox 63

Status

()

VERIFIED FIXED
6 months ago
6 months ago

People

(Reporter: dholbert, Assigned: adw)

Tracking

({regression})

unspecified
Firefox 63
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox61 unaffected, firefox62 unaffected, firefox63+ verified)

Details

(URL)

Attachments

(6 attachments)

(Reporter)

Description

6 months ago
STR:
1. Visit this URL (note: the ip address is from the demo page badssl.com):
https://104.154.89.105/?aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

2. Look at your URL bar.


ACTUAL RESULTS: "https" is outside the URL bar, overlapping the back button.
EXPECTED RESULTS: https should remain inside URL bar.
(Reporter)

Comment 1

6 months ago
This was initially reported in bug 1480355 comment 6. I'm spinning it off to this bug so it's got its own dedicated spot for investigation/fix.

I think this was likely a regression from bug 1480355. At least, I got this partially-narrowed regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=588a314db0d5d2f7d1b758d09f170e3afb1283a3&tochange=d9e6ce390607ad8c227adc2ad2ff3cac89a814bc
...which includes that bug's fix.

(For at least a few days before the start of that ^^ regression range, "https" looks like it's in the wrong position (shifted down somewhat) but it's inside the URL bar at least.)
status-firefox62: --- → unaffected
status-firefox63: --- → affected
tracking-firefox63: --- → ?
Flags: needinfo?(adw)
Keywords: regression
(Reporter)

Comment 2

6 months ago
(In reply to Daniel Holbert [:dholbert] from comment #0)
> STR:
> 1. Visit this URL (note: the ip address is from the demo page badssl.com):
> https://104.154.89.105/
> ?aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaa=bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> bbbbbbbbbbbbbbb
> 
> 2. Look at your URL bar.

I forgot to include, optional step 1b (sometimes necessary):
 1b. click through the cert error page to add an exception.
(Reporter)

Comment 3

6 months ago
Created attachment 8999830 [details]
screenshot 1: before clicking through cert error page (notice "https" overlapping back button)
(Reporter)

Comment 4

6 months ago
Created attachment 8999832 [details]
screenshot 2: after clicking through cert error page (notice "https" overlapping back button)
(Reporter)

Updated

6 months ago
Attachment #8999832 - Attachment description: screenshot 1: after clicking through cert error page (notice "https" overlapping back button) → screenshot 2: after clicking through cert error page (notice "https" overlapping back button)
status-firefox61: --- → unaffected
status-firefox-esr52: --- → unaffected
status-firefox-esr60: --- → unaffected
tracking-firefox63: ? → +
(Assignee)

Updated

6 months ago
Duplicate of this bug: 1481814
(Assignee)

Updated

6 months ago
Assignee: nobody → adw
Status: NEW → ASSIGNED
Flags: needinfo?(adw)

Comment 6

6 months ago
FWIW, while obviously we need to fix this as filed, and ensure that scrolling the URL bar for non-IP addresses doesn't have the same problem, we also really need to make sure that the host is visible in the URL bar, instead of the tail end of the URL.
Just to add more info: this problem has been changing slightly over time and I bisected its history to help out.

Note: it's not necessary to have a broken cert, any https:// url long enough to overflow will do.
Created attachment 9003159 [details]
urlbar-https-prob.mov

Starting in late July, probably from bug 1419391 (this I didn't confirm), the https:// shows up when the URL is scrolled to the end.

I believe this is intentional, but it has a slightly weird interaction when scrolling the URL bar using the mouse wheel or two-finger gestures (see video), because it only shows up when the scrolling reaches the very end.
Created attachment 9003161 [details]
effect from bug 1470910

Then, in the beginning of August, bug 1470910 landed and caused the https:// box to show off center when doing the same action as the video (scrolling a long url to the end)
Attachment #9003161 - Attachment description: Screen Shot 2018-08-22 at 11.19.14 AM.png → effect from bug 1470910

Comment 10

6 months ago
(In reply to :Felipe Gomes (needinfo me!) from comment #7)
> Note: it's not necessary to have a broken cert, any https:// url long enough
> to overflow will do.

Yes, though it also seems that having an IP address as the host here causes breakage in some of the checks we use because of their non-directionality (as opposed to clearly-ltr hosts, like all non-IDN ones that use non-IDN gTLDs), so the URL is scrolled to the end from the beginning, unlike "normal" URLs.
Created attachment 9003164 [details]
effect from bug 1480355

And then, a couple of days later, bug 1480355 landed and caused the https:// box to show underneath the back button
(In reply to :Gijs (he/him) from comment #10)
> Yes, though it also seems that having an IP address as the host here causes
> breakage in some of the checks we use because of their non-directionality
> (as opposed to clearly-ltr hosts, like all non-IDN ones that use non-IDN
> gTLDs), so the URL is scrolled to the end from the beginning, unlike
> "normal" URLs.

Ah so that explains why it's easier to see the problem with an IP address URL
(Assignee)

Comment 13

6 months ago
Created attachment 9003275 [details]
Bug 1483122 - "https" is pushed off left edge of address bar (overlapping buttons!) for long URLs with broken cert configurations

Bug 1470910 broke the positioning because it changed the tag name of .urlbar-input-box but didn't update the related rule in browser.css, and then bug 1480355 landed and made it worse.  This patch fixes the first problem by updating the tag name in the CSS, and it fixes the second problem (and bug 1480355) by setting `direction: ltr` on .urlbar-input-box.

Updated

6 months ago
Blocks: 1480572

Comment 14

6 months ago
Comment on attachment 9003275 [details]
Bug 1483122 - "https" is pushed off left edge of address bar (overlapping buttons!) for long URLs with broken cert configurations

:Gijs (he/him) has approved the revision.
Attachment #9003275 - Flags: review+

Comment 15

6 months ago
Pushed by dwillcoxon@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/265d09efe73f
"https" is pushed off left edge of address bar (overlapping buttons!) for long URLs with broken cert configurations r=Gijs

Comment 16

6 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/265d09efe73f
Status: ASSIGNED → RESOLVED
Last Resolved: 6 months ago
status-firefox63: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
I verified this issue on Mac OS X 10.12, Ubuntu 16.04 and Windows 10 with FF Nightly 63.0a1(2018-08-23) LTR build and RTL build and I can confirm the fix.
Status: RESOLVED → VERIFIED
status-firefox63: fixed → verified
You need to log in before you can comment on or make changes to this bug.