Last Comment Bug 691725 - Unable to use mouse to select an item in Select Drop Down list in 32-bit mode on Mac
: Unable to use mouse to select an item in Select Drop Down list in 32-bit mode...
Status: VERIFIED FIXED
[qa!]
: regression, verified-aurora, verified-beta
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: x86 Mac OS X
: P1 normal (vote)
: mozilla10
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
:
Mentors:
: 690828 691833 692117 (view as bug list)
Depends on:
Blocks: 533460 675553 690828 692068 692117
  Show dependency treegraph
 
Reported: 2011-10-04 05:18 PDT by d.a.
Modified: 2011-12-06 17:52 PST (History)
13 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
fixed
-


Attachments
testcase (236 bytes, text/html)
2011-10-04 14:05 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details
Actually initialize the mIsDragPopup member of nsWidgetInitData. (1.01 KB, patch)
2011-10-05 13:31 PDT, Boris Zbarsky [:bz] (still a bit busy)
enndeakin: review+
christian: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description d.a. 2011-10-04 05:18:48 PDT
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.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 10:48:09 PDT
Worksforme with the 2011-10-03 nightly on OS 10.6...

d.a., does this happen in safe mode?
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 10:52:45 PDT
*** Bug 691833 has been marked as a duplicate of this bug. ***
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 10:53:24 PDT
Confirmed based on duplicate, but I still can't reproduce...
Comment 4 Julian Viereck 2011-10-04 12:45:45 PDT
(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?
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 12:49:56 PDT
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?
Comment 6 d.a. 2011-10-04 13:27:44 PDT
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.
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 14:04:54 PDT
Bingo.  In 32-bit mode I can reproduce the bug. Regression range coming up.
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 14:05:21 PDT
Created attachment 564663 [details]
testcase
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 19:42:06 PDT
Hrm.  Except my debug 32-bit build from changeset f25928e4847d also shows the problem....
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 19:43:15 PDT
Whereas a nightly that claims to be built from that changeset definitely does not.
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 19:51:20 PDT
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...
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 20:04:49 PDT
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.
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 20:44:18 PDT
I'm seeing the regression in a debug build back to Sept 1 so far....
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 21:36:44 PDT
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?
Comment 16 d.a. 2011-10-05 02:51:34 PDT
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.
Comment 17 d.a. 2011-10-05 03:01:21 PDT
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.
Comment 18 d.a. 2011-10-05 03:31:11 PDT
This should be the correct range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb4b93331e4f&tochange=b5b082d183d0

Works in cb4b93331e4f and broken in b5b082d183d0
Comment 20 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 07:43:22 PDT
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?
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 07:49:55 PDT
Actually, let me try with the debug nightlies myself.
Comment 22 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 08:11:25 PDT
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....
Comment 23 d.a. 2011-10-05 08:41:44 PDT
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.
Comment 24 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 09:08:13 PDT
No the hourly archive only goes back a month.
Comment 25 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 09:52:06 PDT
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.
Comment 26 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 11:59:10 PDT
A note to anyone else bisecting: this bug is _not_ 100% reliably reproducible on debug builds.  Close, but not quite 100%.
Comment 27 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 13:25:25 PDT
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.
Comment 28 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 13:30:48 PDT
And thanks to not having renamed PR_TRUE/FALSE, the same patch applies to tip and aurora.  ;)
Comment 29 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 13:31:20 PDT
Created attachment 564985 [details] [diff] [review]
Actually initialize the mIsDragPopup member of nsWidgetInitData.
Comment 30 Neil Deakin (away until Oct 3) 2011-10-05 15:11:42 PDT
Comment on attachment 564985 [details] [diff] [review]
Actually initialize the mIsDragPopup member of nsWidgetInitData.

Good catch.
Comment 31 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 20:23:07 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/3f0e81847318
Comment 32 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 20:24:21 PDT
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.
Comment 33 Ed Morley [:emorley] 2011-10-06 08:36:57 PDT
https://hg.mozilla.org/mozilla-central/rev/3f0e81847318
Comment 34 Boris Zbarsky [:bz] (still a bit busy) 2011-10-06 19:46:08 PDT
https://hg.mozilla.org/releases/mozilla-aurora/rev/aa2f030842c0
Comment 35 d.a. 2011-10-07 06:37:26 PDT
With nightly built from: http://hg.mozilla.org/mozilla-central/rev/c3a50afc2243 I can confirm that this bug is fixed.
Comment 36 Michael Wu [:mwu] 2011-10-07 07:31:30 PDT
*** Bug 690828 has been marked as a duplicate of this bug. ***
Comment 37 Michael Wu [:mwu] 2011-10-07 07:51:51 PDT
*** Bug 692117 has been marked as a duplicate of this bug. ***
Comment 38 Boris Zbarsky [:bz] (still a bit busy) 2011-10-07 07:59:36 PDT
d.a., thanks for confirming that and thank you very much for your help in tracking this down!
Comment 39 Virgil Dicu [:virgil] [QA] 2011-11-30 09:07:25 PST
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.

Note You need to log in before you can comment on or make changes to this bug.