arni2033 Reporter
	Description • 9 years ago

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160110030214
STR:
1. Open the following "data:" url. This is emulation of the situation when a long article loads
> data:text/html,<meta http-equiv="refresh" content="4; url=https://dl.dropboxusercontent.com/s/a06mp7io7mnby9u/unload%20tab.htm?dl=0"/>
2. Hover mouse over the dropmarker (don't move mouse after this step)
  [You must perform Steps 1-2 in less than 4 seconds]
3. Wait 4 seconds
4. Wait until the dropbox page is loaded
5. CLICK!

Result:       
  After Step 5 Reader view button is clicked, and that takes you to unwanted about:reader page
 User is forced to move mouse to the back button in urlbar (across all screen), click it,
 then move mouse to the dropmarker, but don't click it until the page is fully loaded.
  As said in Step 1, this is emulation of the situation when a long article loads. That means that
 user doesn't know when reader view (or any other unwanted icon) appears, so he clicks it accidentally
 instead of the dropmarker.

Expectations: 
  Dropmarker is _Always_ located in urlbar, therefore it shouldn't move on page load.
 There was 2 options: either to keep the dropmarker untouched, or remove it.
  I don't know how the 3rd option "twitch the dropmarker as often as possible" was chosen, but it's not
 a good option. It's like the idea to twitch reload button as often as possible.
 As I underlined in bug 1231025, the more twitching, the harder it is to use the browser.

	:Gijs (he/him)
	Comment 1 • 9 years ago

(In reply to arni2033 from comment #0)
>   I don't know how the 3rd option "twitch the dropmarker as often as
> possible" was chosen

It was chosen because removing visual clutter (which is what that dropmarker is - it is not useful to probably upwards of 90% of Firefox users, 99% of the time) is a Good Idea. There is evidence to back that up. People find software easier to use when they're not overwhelmed with 100 things they don't need (like the reader button which you don't want).

Removing it doesn't work because we need there to be a way to open/close the autocomplete popup with the mouse for the cases where people really do want to do that.

So I don't think there's anything we can do to fix this, so I'm going to mark it WONTFIX. I've needinfo'd Philipp in case he disagrees.

As a workaround, you could put this in your userChrome.css or equivalent:

.urlbar-history-dropmarker {
  opacity: 1 !important;
  -moz-box-ordinal-group: 1000 !important;
}

	arni2033 Reporter
	Comment 2 • 9 years ago

> it is not useful to probably upwards of 90% of Firefox users, 99% of the time) is a Good Idea
I see you're using "95 normal users vs 5 advanced users" model. As you said, 99% of time I, as a normal user, don't look at the toolbar so I don't care what's placed there. After bug 1203494, in that 1% of time I see not a normal button, but a twitching and blinking button. I would definitely choose to remove it completely or to always show.
> Removing it doesn't work
It may work, because currently that dropmarker has very annoying behavior. So an "advanced" user will
either avoid using it OR apply some CSS workarounds anyway. Also, there's F4, Alt+Up/Down for that
> overwhelmed with 100 things they don't need
Come on! Bug 1206244 introduced extra icon in urlbar, and now it's sometimes 3 icons in identity block. Plus verified identity text label. So I can't believe [there was user feedback that said "there're too many icons in urlbar"] && [that feedback complained about dropmarker specifically]

I know how to use userstyles BTW. I made all possible CSS workarounds for bugs I reported (for now),
including obvious bugs. IMO too much twitching and blinking stuff causes eye-strain and even neuroses

Still, I can't work around comment 0 with CSS in general case. It's not true that I don't want/like reader button - I don't like it when the click target is being replaced 0.1s before I click.

	:Gijs (he/him)
	Comment 3 • 9 years ago

(In reply to arni2033 from comment #2)
> > overwhelmed with 100 things they don't need
> Come on! Bug 1206244 introduced extra icon in urlbar, and now it's sometimes
> 3 icons in identity block. Plus verified identity text label. So I can't
> believe [there was user feedback that said "there're too many icons in
> urlbar"] && [that feedback complained about dropmarker specifically]

"Two wrongs don't make a right". I don't think the 3 identity block icons is what we're aiming for, either. Hopefully that will be fixed soon.

> I know how to use userstyles BTW. I made all possible CSS workarounds for
> bugs I reported (for now),
> including obvious bugs. IMO too much twitching and blinking stuff causes
> eye-strain and even neuroses
> 
> Still, I can't work around comment 0 with CSS in general case. It's not true
> that I don't want/like reader button - I don't like it when the click target
> is being replaced 0.1s before I click.

The CSS I provided should move the dropdown icon behind (to the right of) the reader mode icon, so it will stop moving about (that's what the ordinal group CSS property does). AIUI that fixes comment #0.

	(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo
	Comment 4 • 9 years ago

FWIW, I'd love to remove the dropmarker altogether, but should to look at some UI telemetry to see how frequently it is used first.

	arni2033 Reporter
	Comment 5 • 8 years ago

This bug became worse after bug 565718. See STR_2.

>>>   My Info:   Win7_64, Nightly 51, 32bit, ID 20160902030222 (2016-09-02)
STR_2:
1. Open   http://www.rp-online.de/
2. Set zoom level to 120%
3. Open new tab, paste "http://www.rp-online.de/" in urlbar, press Enter
4. While page is still loading, hover mouse over dropmarker in urlbar and click left mouse button

AR:  Button "120%" appears after dropmarker 0.1s before click, therefore browser resets zoom level
     instead of opening suggestions popup. I now have to press Ctrl+"+" twice, then click dropmarker

ER:  Browser shouldn't add irrelevant buttons below mouse pointer 0.1s before click.
     I.e. either X or Y:
 X) Dropmarker should always be the last item in urlbar (before reload button ofc)
 Y) Zoom level button should always be visible in urlbar

Note:
 This case is different from "allow window.open()" button in urlbar, because (just like comment 0)
 it requires user to UNDO action that he didn't even plan to make anyways.

This is regression from bug 565718. Regression range:
> https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=8725f14625e0c87776f9acf66e6712ceca301000&tochange=ef0801fdc7abe018a8b026c00e8bdebcc690001c