Closed Bug 691725 Opened 13 years ago Closed 13 years ago

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

Categories

(Core :: General, defect, P1)

Product:
Core
Component:
General
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla10
Tracking Flags:
Tracking Status
firefox9 - fixed
firefox10 - ---

People

(Reporter: danne.da, Assigned: bzbarsky)

References

Details

(Keywords: regression, verified-aurora, verified-beta, Whiteboard: [qa!])

Attachments

(2 files)

testcase
236 bytes, text/html
Details
Actually initialize the mIsDragPopup member of nsWidgetInitData.
1.01 KB, patch
enndeakin
: review+
christian
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
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?
OS: Mac OS X → Windows XP
Confirmed based on duplicate, but I still can't reproduce...
OS: Windows XP → Mac OS X
(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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted, regressionwindow-wanted
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.
Attached file testcase — 

    
    

    
  
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?

    
  
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

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
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.
Blocks: 675553

    
    

    
  
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.
Assignee: nobody → bzbarsky
Blocks: 533460, 690828, 692117, 692068

          tracking-firefox9:
          --- → ?
Priority: -- → P1

    
    

    
  
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.

        Attachment #564985 -
        Flags: review?(enndeakin) → review+

    
    

    
  
https://hg.mozilla.org/integration/mozilla-inbound/rev/3f0e81847318
Flags: in-testsuite?
Target Milestone: --- → mozilla10

    
    

    
  
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
Closed: 13 years ago
Resolution: --- → FIXED

    
  

        Attachment #564985 -
        Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

    
    

    
  
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!

    
  
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!]

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: