Unable to use mouse to select an item in Select Drop Down list in 32-bit mode on Mac

VERIFIED FIXED in Firefox 9

Status

()

Core
General
P1
normal
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: d.a., Assigned: bz)

Tracking

({regression, verified-aurora, verified-beta})

Trunk
mozilla10
x86
Mac OS X
regression, verified-aurora, verified-beta
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox9- fixed, firefox10-)

Details

(Whiteboard: [qa!])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a1) Gecko/20111003 Firefox/10.0a1
Build ID: 20111003080738

Steps to reproduce:

When trying to select an item in a Select Drop Down list clicking an item with the mouse will click through the actual list and instead click whatever is behind it. 

STR on Bugzilla:
1. Find a bug where you can change the Platform OS
2. Select Windows XP, or whatever OS is rendered above the "(vote)" link.

Instead of Selecting Windows XP, it will click the vote link, taking you to that page. 

This only seems to affect the HTML Select, not any drop downs used in the application itself, like the preferences section.
(Assignee)

Comment 1

6 years ago
Worksforme with the 2011-10-03 nightly on OS 10.6...

d.a., does this happen in safe mode?
OS: Mac OS X → Windows XP
(Assignee)

Updated

6 years ago
Duplicate of this bug: 691833
(Assignee)

Comment 3

6 years ago
Confirmed based on duplicate, but I still can't reproduce...
OS: Windows XP → Mac OS X

Comment 4

6 years ago
(In reply to Boris Zbarsky (:bz) from comment #1)
> 
> d.a., does this happen in safe mode?

Yes, still the same bug. I have a MacBook 1,1, that's quite old and I think there is no hardware acceleration. Could that make a difference?
(Assignee)

Comment 5

6 years ago
Perhaps, but I just tried to disable hardware acceleration over here and I still can't reproduce....

Are you willing to hunt down a regression range?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted, regressionwindow-wanted
(Reporter)

Comment 6

6 years ago
I'll check for the regression window tomorrow, but it's quite recent, within the last 3 days or so.

I run Firefox in 32-bit mode, if that makes any difference.
(Assignee)

Comment 7

6 years ago
Bingo.  In 32-bit mode I can reproduce the bug. Regression range coming up.
(Assignee)

Comment 8

6 years ago
Created attachment 564663 [details]
testcase
(Assignee)

Comment 9

6 years ago
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f25928e4847d&tochange=90575e23ea93
tracking-firefox10: --- → ?
Keywords: qawanted, regressionwindow-wanted → regression
(Assignee)

Comment 10

6 years ago
Hrm.  Except my debug 32-bit build from changeset f25928e4847d also shows the problem....
(Assignee)

Comment 11

6 years ago
Whereas a nightly that claims to be built from that changeset definitely does not.
(Assignee)

Comment 12

6 years ago
I'm doing some builds from a few days prior, but there's a chance that the bug was present for a while and then suddenly popped up in opt builds for some reason...
(Assignee)

Comment 13

6 years ago
I suppose I could bisect on opt builds if we really care about what made the bug appear there, but I'm going to look for a debug regression range first.
(Assignee)

Comment 14

6 years ago
I'm seeing the regression in a debug build back to Sept 1 so far....
(Assignee)

Comment 15

6 years ago
My opt build from rev f25928e4847d also shows the bug.. but the nightly doesn't seem to.

d.a., would you mind confirming that regression range, just to make sure I'm not on crack here?
(Assignee)

Updated

6 years ago
Summary: Unable to use mouse to select an item in Select Drop Down list → Unable to use mouse to select an item in Select Drop Down list in 32-bit mode on Mac
(Reporter)

Comment 16

6 years ago
The first build I tested was the nightly built from: http://hg.mozilla.org/mozilla-central/rev/f25928e4847d 

I'm going back to some older builds to see when it appears for me running it in 32-bit.
(Reporter)

Comment 17

6 years ago
Something weird is going on:

Using the testcase I can reproduce it with the above build,
however if I can change the OS field here with the same build, as well as all the other drop down lists on this bug except for the status (below comment field) and the Flags drop downs.
(Reporter)

Comment 18

6 years ago
This should be the correct range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb4b93331e4f&tochange=b5b082d183d0

Works in cb4b93331e4f and broken in b5b082d183d0
(Reporter)

Comment 19

6 years ago
Even more reduced range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb4b93331e4f&tochange=a44d328b9f44

Maybe bug 687393?
(Assignee)

Comment 20

6 years ago
Seems unlikely, but I'll do some builds from that range and see what I find.

d.a., if you use debug nightlies, how far back do you see the bug?
(Assignee)

Comment 21

6 years ago
Actually, let me try with the debug nightlies myself.
(Assignee)

Comment 22

6 years ago
With debug nightlies, I seem to be down to http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a41b781330a6&tochange=5d9989c3bff6 and http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ecb597abc0bf&tochange=0d1dd45a06fc

I guess I get to do more debug builds....
(Reporter)

Comment 23

6 years ago
Any hourly archive going back more than the month available on the FTP? Would have been easier to go through the mozilla-inbound had there been some hourly builds on the 23rd.
(Assignee)

Comment 24

6 years ago
No the hourly archive only goes back a month.
(Assignee)

Comment 25

6 years ago
OK, bisecting on opt builds for the range from comment 19, I get:

The first bad revision is:
changeset:   77799:e7854b4d29ba
user:        Michael Wu <mwu@mozilla.com>
date:        Wed Sep 28 23:19:26 2011 -0700
summary:     Bug 675553 - Switch from PRBool to bool on a CLOSED TREE , r=bsmedberg,khuey,bz,cjones

Clearly this just made a latent bug (which was present in debug builds way before then) show up.

Still bisecting the debug builds.
Blocks: 675553
(Assignee)

Comment 26

6 years ago
A note to anyone else bisecting: this bug is _not_ 100% reliably reproducible on debug builds.  Close, but not quite 100%.
(Assignee)

Comment 27

6 years ago
The underlying issue is from bug 533460.  The new mIsDragPopup on nsWidgetInitData is not initialized in the constructor.  We apparently got lucky in some cases with it being set to false, but not on debug 32-bit Mac.  And with the bool changes not on 32-bit mac in general.

This may also be causing bug 690828 and bug 692117 and maybe bug 692068.
Assignee: nobody → bzbarsky
tracking-firefox9: --- → ?
Priority: -- → P1
(Assignee)

Comment 28

6 years ago
And thanks to not having renamed PR_TRUE/FALSE, the same patch applies to tip and aurora.  ;)
(Assignee)

Comment 29

6 years ago
Created attachment 564985 [details] [diff] [review]
Actually initialize the mIsDragPopup member of nsWidgetInitData.
Attachment #564985 - Flags: review?(enndeakin)
Comment on attachment 564985 [details] [diff] [review]
Actually initialize the mIsDragPopup member of nsWidgetInitData.

Good catch.
Attachment #564985 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 31

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/3f0e81847318
Flags: in-testsuite?
Target Milestone: --- → mozilla10
(Assignee)

Comment 32

6 years ago
Comment on attachment 564985 [details] [diff] [review]
Actually initialize the mIsDragPopup member of nsWidgetInitData.

Requesting aurora approval.  This should be pretty safe (it's just initializing a variable that used to have a random value), and should prevent other aurora changes from accidentally tickling bugs due to this member not being initialized.
Attachment #564985 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/3f0e81847318
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Attachment #564985 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 34

6 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/aa2f030842c0
status-firefox9: --- → fixed
(Reporter)

Comment 35

6 years ago
With nightly built from: http://hg.mozilla.org/mozilla-central/rev/c3a50afc2243 I can confirm that this bug is fixed.

Updated

6 years ago
Duplicate of this bug: 690828

Updated

6 years ago
Duplicate of this bug: 692117
(Assignee)

Comment 38

6 years ago
d.a., thanks for confirming that and thank you very much for your help in tracking this down!
Whiteboard: [qa+]
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20100101 Firefox/9.0 beta 3
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0a2) Gecko/20111130 Firefox/10.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0a1) Gecko/20111130 Firefox/11.0a1

Verified using the tescase from the attachment. Selecting drop down lists works normally now, both in 32 and 64 bit mode.
Status: RESOLVED → VERIFIED
Keywords: verified-aurora, verified-beta
Whiteboard: [qa+] → [qa!]

Updated

6 years ago
tracking-firefox10: ? → -
tracking-firefox9: ? → -
You need to log in before you can comment on or make changes to this bug.