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.

Worksforme with the 2011-10-03 nightly on OS 10.6... d.a., does this happen in safe mode?

Confirmed based on duplicate, but I still can't reproduce...

(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?

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?

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.

Bingo. In 32-bit mode I can reproduce the bug. Regression range coming up.

Hrm. Except my debug 32-bit build from changeset f25928e4847d also shows the problem....

Whereas a nightly that claims to be built from that changeset definitely does not.

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...

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.

I'm seeing the regression in a debug build back to Sept 1 so far....

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?

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.

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.

This should be the correct range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb4b93331e4f&tochange=b5b082d183d0 Works in cb4b93331e4f and broken in b5b082d183d0

Even more reduced range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb4b93331e4f&tochange=a44d328b9f44 Maybe bug 687393?

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?

Actually, let me try with the debug nightlies myself.

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....

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.

No the hourly archive only goes back a month.

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.

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

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.

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

Comment on attachment 564985 [details] [diff] [review] Actually initialize the mIsDragPopup member of nsWidgetInitData. Good catch.

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.

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

d.a., thanks for confirming that and thank you very much for your help in tracking this down!

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.