Closed Bug 1610497 Opened 10 months ago Closed 10 months ago

Address bar can not be selected by mouse if the browser has the minimum width

Categories

(Firefox :: Address Bar, defect, P2)

defect
Points:
3

Tracking

()

VERIFIED FIXED
Firefox 74
Tracking Status
firefox-esr68 --- unaffected
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- verified

People

(Reporter: ccomorasu, Assigned: dao)

References

(Regression)

Details

(Keywords: perf-alert, regression)

Attachments

(2 files)

Affected versions

  • Fx 74.0a1
  • Fx 73.0b7
  • Fx 72.0.2

Affected platforms

  • Windows 10 x64
  • Ubuntu 18.04 LTS
  • macOS 10.14

Steps to reproduce

  1. Launch Firefox.
  2. Go to "https://www.mozilla.org/en-US/contribute/stories/" .
  3. Change the browser width to the minimum.
  4. Attempt to select the address bar with the mouse cursor.

Expected result

  • The address bar is selected.

Actual result

  • The address bar can not be selected.

Regression range

Additional notes

  • Builds that have the permanent search icon in front of the megabar are not affected (https://bugzil.la/1589836).
  • This issue is not reproducible if the address bar is set in focus using the keyboard ( Ctrl/Cmd + L).
Has Regression Range: --- → yes
Has STR: --- → yes
Priority: -- → P3
Summary: Address bar can not be selected if the browser has the minimum width → Address bar can not be selected by mouse if the browser has the minimum width
Regressed by: 1580538
Depends on: 1598563
Keywords: blocked-ux

proposal is to increase min window width to 500px

Priority: P3 → P2

(In reply to Marco Bonardo [:mak] from comment #1)

proposal is to increase min window width to 500px

Turns out we tried 390 (non-Mac) / 425 (Mac) before and there was backlash. So I think jumping to 500 just because this matches Chrome is a bit too hasty. I tried 400 just now and it seems to solve our immediate problem here.

Assignee: nobody → dao+bmo
Blocks: 1585980, 1598563
Status: NEW → ASSIGNED
Points: --- → 2
No longer depends on: 1598563

Looking at tests now...

Points: 2 → 3

(In reply to Dão Gottwald [::dao] from comment #2)

Turns out we tried 390 (non-Mac) / 425 (Mac) before and there was backlash.

Could you please point out which kind of negative feedback that brought, and how much time ago? I'm not sure which important use-cases it would break, and we should still report reasons when we pick a direction.
I think we should stick to UX requirements and evaluate fresh feedback on it, we have time for that. While your screenshot is usable, one can easily have 3 or 4 action buttons active in the urlbar and those do not collapse (maybe they should!)

(In reply to Marco Bonardo [:mak] from comment #5)

(In reply to Dão Gottwald [::dao] from comment #2)

Turns out we tried 390 (non-Mac) / 425 (Mac) before and there was backlash.

Could you please point out which kind of negative feedback that brought, and how much time ago? I'm not sure which important use-cases it would break, and we should still report reasons when we pick a direction.

Bug 897160 comment 21 and below, six years ago. I think it was mainly people quickly testing responsive design without wanting to go through devtools responsive design mode. I expect people still to that today.

I think we should stick to UX requirements and evaluate fresh feedback on it, we have time for that.

What are the requirements? What specific bugs do we want to solve here? 400 seems to address this particular bug which I though was a requirement. With the two-line layout we also show more characters in the results than without the megabar, which I thought was our other goal.

While your screenshot is usable, one can easily have 3 or 4 action buttons active in the urlbar and those do not collapse (maybe they should!)

Yeah, collapsing seems like a smarter way to address that. Otherwise, even just with the zoom button and reader mode, it's just too easy to get into a situation where even 500 won't help.

(In reply to Dão Gottwald [::dao] from comment #6)

Bug 897160 comment 21 and below, six years ago. I think it was mainly people quickly testing responsive design without wanting to go through devtools responsive design mode. I expect people still to that today.

It made sense at the time, but indeed now people should use devtools, and should be pointed to them if they still don't. Because no other browser does that, people should not be particularly used to the old method. I don't think it's a valid use-case nowadays.

Yeah, collapsing seems like a smarter way to address that. Otherwise, even just with the zoom button and reader mode, it's just too easy to get into a situation where even 500 won't help.

We should try to cover vast mayority of common cases, zoom is indeed an interesting point (that I honestly missed) that seems to suggest we should pick the larger size.

(In reply to Marco Bonardo [:mak] from comment #8)

(In reply to Dão Gottwald [::dao] from comment #6)

Bug 897160 comment 21 and below, six years ago. I think it was mainly people quickly testing responsive design without wanting to go through devtools responsive design mode. I expect people still to that today.

It made sense at the time, but indeed now people should use devtools, and should be pointed to them if they still don't. Because no other browser does that, people should not be particularly used to the old method. I don't think it's a valid use-case nowadays.

There's nothing really old about resizing a browser window, and it seems like the most intuitive and fastest way to check how responsive a page is. Somebody there also mentioned wanting to check multiple pages in separate tabs at the same time, also an interesting use case. "Use devtools" was already the first response back then but it wasn't received well. I think to some extent we need to accept that different people will want to use different methods to perform a task.

Yeah, collapsing seems like a smarter way to address that. Otherwise, even just with the zoom button and reader mode, it's just too easy to get into a situation where even 500 won't help.

We should try to cover vast mayority of common cases, zoom is indeed an interesting point (that I honestly missed) that seems to suggest we should pick the larger size.

The thing is, a larger size would only be a stop-gap solution as it would still be easy to get into a situation where it won't help (unless you're suggesting something even bigger than 500). If we really want to address those cases we'll need to collapse more stuff, but then it seems that 400 should work fine as a minimum...

I've discussed this with Verdi and Connor as well. Here are some notes/ asks resulting from that conversation:

Dão, can you please make builds available for 500px and 400px, so that we can properly evaluate both?

I think there's value in applying this min-width only browser windows that show the navbar. Is this the case in the patch you attached here? If not, let's discuss what the cost would be to make that happen.
My thought here is to scope down the potential impact of this change to apply to our use case only (as much as possible), whilst allowing for workarounds for use cases we may be limiting here. For example, for responsive design testing one could create a simple landing page that'll show <button onclick="window.open('...', 'designTest', 'toolbar=no');">Click to test</button> and resize it at will.

Blocks: 1611930
See Also: → 1401835

(In reply to Mike de Boer [:mikedeboer] from comment #10)

I've discussed this with Verdi and Connor as well. Here are some notes/ asks resulting from that conversation:

Dão, can you please make builds available for 500px and 400px, so that we can properly evaluate both?

After playing around this I'm now using 450px instead of 400px for a bit more breathing room. I'm also hiding the zoom button when the window gets narrower than 550px. This seems like a good compromise to me, addressing the most common scenarios, the rest should be handled in bug 1401835 (out of scope for megabar imho). Builds below.

450px:

500px:

I think there's value in applying this min-width only browser windows that show the navbar. Is this the case in the patch you attached here? If not, let's discuss what the cost would be to make that happen.

The min-width only applies to normal browser windows, not to popup windows. (Note that we do display the address bar in popup windows. You can't type and there's no search, but it displays stuff as it would in a normal window.)

See Also: → 1545046

(In reply to Dão Gottwald [::dao] from comment #11)

This seems like a good compromise to me, addressing the most common scenarios, the rest should be handled in bug 1401835 (out of scope for megabar imho).

Looking at that bug again, although I still think it doesn't necessarily need to be fixed as part of the megabar, I think it would actually be doable without much effort because the page action buttons are already duplicated in the page action menu.

Blocks: 1612317
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9e65d54c2de3
Increase browser window min-width so the address bar can be focused by mouse. r=mak
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 74

== Change summary for alert #24831 (as of Sun, 02 Feb 2020 03:31:47 GMT) ==

Regressions:

4% tart linux64-shippable opt e10s stylo 2.07 -> 2.15

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=24831

I can confirm this issue is fixed, I verified using Fx 74.0a1(2020-02-02) on Windows 10 x64, Ubuntu 18.04 and macOS 10.14.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.