1248500 - Dropdown menu buttons will not depress

Status: NEW

(Core :: Widget: Win32, defect, P5)

Description

[Thomas E.]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0 K-Meleon/75.0
Build ID: 7500

Steps to reproduce:

Open <http://www.w3schools.com/html/tryit.asp?filename=tryhtml_elem_select> in Mozilla Firefox or any other Web page with a <select> element.


Actual results:

I can click on the drop-down menu button, and the list will drop down and is selectable, but the button will not depress.


Expected results:

The selector button should depress and the menu should drop down.

Regular buttons will depress which shows to the user that their computer is responsive and the buttonpress was successful.

This bug was present at least as far back as Gecko 1.9.1.17 (contemporary with Firefox 3.5) and persists to the current stable version of (44.0.2 at the time of writing.)

All of the standard form elements of HTML 2.0 and the standard UI elements of the operating system should be fully supported in Gecko.  I have observed this in multiple versions of Microsoft Windows, but I suspect this is an issue regardless of operating system.

Thanks,
     Thomsa

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f570b2539bc0&tochange=aa75d2c8a862

Comment 2

[Mats Palmgren (inactive)]

I suspect the expected result varies between systems.  E.g. on my Linux+KDE desktop, a native
combobox button is displayed as pressed while the menu is open.

Comment 3

[arni2033]

(In reply to Alice0775 White from comment #1)
> Regression window:
> https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f570b2539bc0&tochange=aa75d2c8a862
This regression window was obtained using either WinXP or "classic theme" on Windows, right?
Because bug 410719 changed literally nothing on my default Win7 theme
(I can confirm change in "classic theme" though)

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

Can't reproduce on OS X, Andrei, can your team have a look to see if this affects current versions? Thanks!

Comment 5

[Paul Silaghi, QA [:pauly]]

I'm not sure I understand the problem here.
(In reply to Thomas E. from comment #0)
> Actual results:
> I can click on the drop-down menu button, and the list will drop down and is
> selectable, but the button will not depress.
Why should it depress? The blue border around the drop-down list and the blue button around the arrow show that the dropdown is open. Chrome also shows the same blue border. Tested on FX 48.0.2, Win 7.

Comment 6

[Paul Silaghi, QA [:pauly]]

Comparing Win 7 vs Win XP, I see:
blue border on focus, black border without focus - Win 7
blue border on focus & without focus - Win XP
So perhaps, this is the real problem, on Win XP ?

Comment 7

[Thomas E.]

(In reply to Paul Silaghi, QA [:pauly] from comment #5)

> Why should it depress?

It is always a good thing to ask Why.

The button should depress because you are pressing a button!


I will never forget the Joy of pushing the button which opened the front door of my local WAL*MART as a young child.  Not only was its beautiful, pure red colour, surrounded by its lovely chrome plate absolutely irresistible, *especially* for a child, and its surface was pleasantly contoured to the finger of the operator, but pushing that button was a treat which made the trip worthwhile!
In later years these once-ubiquitous buttons were largely put out of a job by the "electric eye", which sensed the motion of anyone near.  While this was an amazing development, the operation of which far beyond my comprehension, that automatic experience did not hold the incredible Joy of Button-pushing.


How is this personal anecdote relevant to the contents of a Bugzilla report you might ask?

Because it is about the Joy of well-designed objects, which rival the creations of Nature, and Buttons in particular, which I've found to bring Joy to my life which is unmatched and indispensable!
This is why particularly discriminating people like myself spend so much time and money seeking and attaining the finest keyboards in the land on all our "devices", and why the thirty-year-old IBM Model M keyboard commonly sells for hundreds of dollars whenever one appears for sale online.

I have always been a strong believer that the Personal Computer, like all well-designed objects, should bring great Joy into life by using, and even simply observing it!

When Douglas Englebert (the man who brought to life his and Vannevar Bush's great vision of the Personal Computer, a device which augmented the quality of life and intelligence of its master) created the mouse in 1963 for his oNLine System, this selection device was made for clicking on things.  In a short while, it only made sense to introduce a virtual Button for clicking, to increase the precision and clarity of this new Graphical User Interface.

When Microsoft released Windows 3.0 in 1992, it brought not only an enormous amount of quality art to its system by user interface art pioneer Susan Kare of Macintosh fame, it also brought a third dimension to the virtual buttons throughout its user interface elements which served as the systemwide standard way to interact with all programs on-screen (unlike the days of CP/M and MS-DOS which had no standard and each program implemented its own GUI internally if it wished to do so.

Capitalist corporations like Microsoft have one main goal: to make the greatest profit possible.  They have shown that to be their motive by their actions time and time again.

At one time (the 90s), it was in Microsoft's best interest to create software that was as user-friendly as possible, in particular, software the was *more* user friendly than that found on the Apple Macintosh system.

That is why Microsoft put such an enormous amount of time, effort, and money into creating the most joyful to use, user-friendly operating system ever seen.  They used iterative design to out-do Apple at their own game, and ended up with Windows 95, the most revolutionary user interface seen since the Macintosh in 1984, eleven years prior!  Once they had applied this interface to MS-DOS Windows' successor Windows NT with NT 4.0, and hardware development caught up, they were unstoppable!

Almost immediately after they had achieved these great feats, user-friendly software was no longer so important to them.
Likewise, once they had squashed Netscape Navigator bu achieving 95% market share with their Internet Explorer (by creating an extremely customizable and user-friendly [though perhaps Web developer hostile] browser), they laid off the entire Internet Explorer development team, which is what allowed the Phoenix, Mozilla, to rise from its ashes, which of course became Firebird, and then Firefox.

When I visit the homepage of mozilla.org on this day, I am immediately greeted with the words "Internet for people,
not profit."  It is the title of the page, and I would assume this is the message they are trying to commiuniate about what kind of organization they are.  Being an organization that puts people first, I would assume that this includes ensuring a Joyful user experience for the people who use their flagship product.

The text immediately after that introduction is as follows:
"Hi. We’re Mozilla, the proudly non-profit champions of the Internet, helping to keep it healthy, open and accessible to all. "

I would think accessibility part would include users of diverse operating systems, including everyone on Windows XP.  (Many computers will not run properly with anything newer, and other users aren't willing to give up usability, reliability, and sovereignty over their operating system for any reason.)


To remind you this isn't just an insignificant personal preference of a particularly demanding user, but rather a very basic feature which pervades every Mozilla product and derivative, I'll include a few snippets from the The Microsoft Windows Interface Guidebook:

To quote the section regarding the value of Directness: "Design your software so that users can directly manipulate software representations of information. Whether
dragging an object to relocate it or navigating to a location in a document, users should see how the actions they take
affect the objects on the screen. Visibility of information and choices also reduce the user's mental workload. Users
can recognize a command easier than they can recall its syntax.
Familiar metaphors provide a direct and intuitive interface to user tasks. By allowing users to transfer their
knowledge and experience, metaphors make it easier to predict and learn the behaviors of software-based
representations."

To quote the section regarding aesthetic values: "...It is important to
remember that every visual element that appears on the screen potentially competes for the user's attention."

Therefore this "blue box" around the input element you describe might be distracting or confusing to a user, but communicates nothing that I can see and has no value or purpose.

Also remember that the standard HTML form elements are meant to conform to the user interface of the system that is being used, so I'd think that the Windows Interface Guidebook would be a good guide to go by for this Windows bug.

Comment 8

[Thomas E.]

This bug seemingly effects any version of Windows using the Standard/Classic interface, but not necessarily when themed.  Windows 7 affection has been confirmed by arni2033 above.

Marked as P1 according to Alex Faaborg's recommendation: https://bugzilla.mozilla.org/show_bug.cgi?id=410719#c21

A reminder that this bug is essentially the re-opening of the over-10-year-old Bug 288082 and Bug 410719, both of which have patches submitted.
Is there more to this issue than re-applying a patch?

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

When I tried to reproduce this issue, I noticed that right upon the time I clicked, the color of the button changed and flashed, then right away the color changed back. Doesn't the "flash" behavior meet the comment 0 expected behavior? May I ask for clarification on the expected behavior here? Screenshot or a video clip is appreciated as well.

Hi Dao,
I am also flagging on you as you fixed bug 410719. It would be great to have your input on the expected behaviour and suggestion for the priority of this bug.

Thanks!

Comment 10

[Dão Gottwald [:dao]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #9)
> May I ask for clarification on the expected behavior here?
> Screenshot or a video clip is appreciated as well.

Ditto, this bug is a bit confusing. Screenshots before / after the regression would have been helpful.

> Hi Dao,
> I am also flagging on you as you fixed bug 410719. It would be great to have
> your input on the expected behaviour and suggestion for the priority of this
> bug.

We don't support Windows XP anymore starting with Firefox 53 (current mozilla-central). So at this point, if I read this bug correctly, only Windows 7 classic without e10s is affected. Based in that I'd suggest we resolve this bug as WONTFIX.

Comment 11

[Jim Mathies [:jimm]]

we should display a depressed state on this button but don't, we just display the highlight. very polishy, non-e10s. Low priority.

Comment 12

[Thomas E.]

Quoting again from the Microsoft Windows Interface Guidebook:
"Users should see how the actions they take affect the objects on the screen."

Some may consider this "minor" or a manner of polish, however, it is a serious failure to correctly implement a very basic user interface element, which is ubiquitous through both the application chrome and basic HTML (ever since it was standardized in HTML 2.0)

I am dismayed to hear the Windows XP support cutoff date has been announced.  A huge setback in accessibility, given how it's the third most-used operating system in the world, about four TIMES higher than Linux.
However, until that date next year, Windows XP is still fully supported.

Please do not underestimate the importance of the standard Windows interface.  Due to its customizability, it is the only option for many power users and people with visual impairments whether in Windows 95 or Windows 7.  It ought to function properly in Mozilla applications just as it does in others, as I said, Mozilla touts accessibility of the Web proudly on their home page and I would hope this is not baseless marketing.

I have tested this further, and as I suspected, this drop-down menu button is broken whether using the standard Windows interface or a theme on top such as Luna or Aero.  I can see, testing this on a computer running on Windows 7 with the default Aero theme, the button depression effect is more subtle, but it is still there in Windows, and still broken in Mozilla.

If you are using the Aero theme and are confused about this, open Windows Explorer and try clicking on the button to the right of the Address Bar which will depress, and open a dropdown menu of where you've been.  Do the same in any Mozilla Application after 1.9.2 and see how the button doesn't move like it's stuck.

I am curious what this has to do with e10s.


(In reply to Hsin-Yi Tsai [:hsinyi] from comment #9)
> When I tried to reproduce this issue, I noticed that right upon the time I
> clicked, the color of the button changed and flashed, then right away the
> color changed back. Doesn't the "flash" behavior meet the comment 0 expected
> behavior? May I ask for clarification on the expected behavior here?
> Screenshot or a video clip is appreciated as well.

I think Jim re-iterates the problem effectively, but if anyone would still benefit from screenshots or a video, then let me know.  The only reason I haven't yet is that it takes time, a video would take more time, and it's something that looks somewhat different in each UI.  This is why the OS/UI handles this, and the Mozilla application shouldn't have to know anything about how the button should look.

I am having trouble imagining this "flashing" behaviour, as this only happens to drop-down box selections on the Macintosh as far as I know.  If you tell me which OS/UI you are using, I can show or tell you what it should look like exactly, but generally, buttons depress when you push them, whether they are operating a drop-down menu, a scrollbar, or anything else.

Comment 13

[Thomas E.]

Attachment: A visual example of correct implementation of the HTML 2.0 standard's SELECT element.

Hello all,

As I haven't seen anything here in a while, I thought I would upload this visual example to help illustrate a working model (from MSIE).

The image shows a screenshot of the popular Web site, "The Death Clock" with an overlaid screen shot (on the right) displaying correct behaviour when the button operating the dropdown menu is pushed.

This is the correct implementation for a visual Web browser of the <SELECT> element as standardized by Sir Tim Berners-Lee in HTML 2.0. <https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.1.3>

I would hope that completing full and correct implementation of HTML 2.0 is a much higher priority than HTML 3, 4, 5, 6....

Hopefully this helps clarify the issue, which I will remind everyone is afflicting all Windows systems, whether they use the Standard/Classic interface or use a skin on top, such as "Luna" or "Aero".

Thanks! :)

Comment 14

[Thomas E.]

Hello everyone,

I thought I ought to change this bug to P1, given how Alex Faaborg (Firefox UX) marked its previous appearance (410719):

"This bug's priority relative to the set of other polish bugs is:
P1 - Polish issue that appears in the main window, or is something that the user may encounter several times a day.

This bug [affects] a lot of control types, so definitely P1."

I'm not sure what is considered a "polish bug" here, but this bug is so pervasive and so violates the user's expectations and consistency of their experience that I personally wouldn't consider it one!  Remember, that this is not a bug that is found on the odd exotic Web site.  It's unavoidable when using any site with a dropdown menu, including library catalogues and other search engines, altering this bug here on Bugzilla, and *within* the interfaces of every other program which uses this codebase, even in offline operations such as changing settings!

I don't understand how to use all these tracking tags, but I truly hope that this bug can be fixed again *before* support ends for Firefox 52 ESR!  There is still over a month left of support, according to the ESR page: <https://www.mozilla.org/en-US/firefox/organizations/>, and I think this sort of bug is clearly in scope for repair even at this stage, considering the other visual bugs of *far* less impact and importance which have been fixed in this period.  I've also removed the "e10s disabled" from the title since I don't see how that's relevant, but feel free to add it back if I'm wrong!

This is such a crucial and pervasive bug, it would be a huge deal to many of the countless people that this will affect!
Remember that although this bug affects everyone on Microsoft Windows up to the latest versions of browser and OS, the people running Windows XP and Vista in particular, as well as those using traditional Firefox add-ons, complete themes, and/or Netscape plugins, will be left with Firefox 52 ESR forever, and I'd be happy to have at least *one* Mozilla browser that works properly for the most basic of tasks, given that Internet Explorer is getting more and more denials of service with all the stringent new HTTPS requirements of the past couple of years, which are ever increasing!


Thanks for your consideration!

                            Thomas

Comment 15

[Ryan VanderMeulen [:RyanVM]]

That isn't how priority flags are used these days. They're used to for work planning (i.e. P1 = working on this right now). Not tracking for any active releases.