Closed Bug 13960 Opened 25 years ago Closed 25 years ago

[DOGFOOD] bugzilla platform dropdowns set themselves

Categories

(Core :: Layout: Form Controls, defect, P1)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: pollmann)

References

Details

Attachments

(1 file)

Test case
127 bytes, text/html
Details 
Lame summary, but I couldn't think of a better short description.  Here's what
happens: mcafee is using seamonkey to make changes to existing bugs, and
whenever he does, the platform on that bug (which was set to something already)
gets changed to reflect the platform where he most recently made the change.
This is a problem on some bugs where the platform is an important part of the
bug report.

Marking dogfood since being able to use bugzilla internally is one of our
dogfood milestones.
Assignee: kmcclusk → rods
Component: XP Toolkit/Widgets → Browser-General
OS: All → HP-UX
dup of one I just filed?
rods
*** Bug 13959 has been marked as a duplicate of this bug. ***
Severity: normal → critical
Priority: P3 → P1
This is now corrupting many of the bugs I am changing
with apprunner, adding leger, chofmann and marking more important.
This may be related to the changes I made Tuesday night to enable session
history.  Any chance you're using the forward or back buttons to navigate to the
bug when this happens?
This happens w/o forward & back,
I type in a bug, go look at some combobox values,
behavior as describe still shows up.
Assignee: rods → pollmann
It sounds like something that Eric is involved with. I don't think it has to do
with my combo work. Assigning to eric for now.
Status: NEW → ASSIGNED
All of my testing with session history showed that this was working like it was
supposed to.  Chris or Akkana, is the selection that is being selected
incorrect?  i.e. Bearing in mind that if the forward/back arrows are used to
navigate, form element values will be restored, is this still doing something
funky?

I am about to check in a fix so that when the selection is updated, the selected
option will scroll into view for GFX combos.  This may help make the selection
more obvious.
Component: Browser-General → HTML Form Controls
OS: HP-UX → All
Priority: P1 → P2
Target Milestone: M11
I just checked in the aforementioned fix.  Let me know if this fixes your
problem.  If not, I'll need more specific instructions on how to reproduce.

(I'm setting the OS to all, milestone to M11, and Component to HTML Form
Controls in the bugreport using apprunner.)
QA Contact: beppe → cpratt
Changing QA contact based on new Component. btw, if the fix is checked in, in
which build should I see it? 19990917xx? And should we change the Status to
FIXED?
Looks like we're not sure if this is fixed or not.
Lemme pull and try this.
This is still very broken using 9/17 builds, see bug 14236 if you would like,
it's a test bug I filed. To reproduce:

1. Goto bugzilla.mozilla.org and select enter new bug
2. Select Browser link and login if need be
3. You should be on the enter bug page. I set the component to autofill,
assigned to mcafee and pressed commit. All fields should have been set to other,
except priority=normal and component=Autofill
4. Press Commit

Results: OS got set to Mac System 7 (should have been other). Also Platform got
set to PC (should have been other). Also severity got set to trivial (should
have been normal)

This was on windows95 using 9/17 morning builds.

I then reloaded the bug, and pressed commit without changing anything (several
times) and saw similar results. For example, the OS kept changing each time.
Priority: P2 → P1
Bug still happening on linux.  Visit two bugs, peek at the component dropdown
for each.  First bug's component selection will match "unpopped" display, second
will not.

This is P1, we need to fix this.  I can't use bugzilla/apprunner without this.
I'm looking at the bug today, please call me at home (650) 494-9025.
I've been looking at this for a little while now too.  What I'm seeing is that
every now and then, right as a combo box is being dropped down, it is receiving
a 'mouse moved' event (even when the pointer is being held very still).  This is
deselecting the correct option in the listbox, then selecting the first option
instead.  The stack looks like this:

#0  nsListControlFrame::SetContentSelected (this=0x89c9290, aIndex=1,
aSelected=0) at nsListControlFrame.cpp:1202
#1  0x40d9bcd0 in nsListControlFrame::MouseMove (this=0x89c9290,
aMouseEvent=0x89ef6f8) at nsListControlFrame.cpp:2111
#2  0x40c786dc in nsEventListenerManager::HandleEvent (this=0x89f3320,
aPresContext=@0x88078b0, aEvent=0xbffff3bc, aDOMEvent=0xbfffefe4, aFlags=2,
aEventStatus=@0xbffff2ec) at nsEventListenerManager.cpp:646
<full trace included in attachment>

I'm looking into why this is happening.  Chris, is the option you see being
wrongly selected always the first option on this drop-down list?  What platform
are you using?
It is sometimes the first element selected, yes.
I am on Linux, paulmac reports this is happening on NT as well.
I think I may have a fix, just a sec...
In my tree, I backed out mozilla/layout all the way back
to 9/14 and marched it forward, I figured out that this
broke between 8pm & 11pm on 9/14.  I was looking at pollmann's
checkins, not sure if that's it but ? it's my closest guess.
Working with pollmann on irc now..
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Checked in a fix (hopefully)  To verify, fire up apprunner.

Visit the attachment (I'm going to attach momentarily), then drop down the combo
box.  B should be selected.  Reload the page and repeat.  If this succeeds many
times in a row, the bug is fixed.
Attached file Test case — 

    
    

    
  
Yes!  This looks much better now.
Tested on linux, apprunner.

    
  
Blocks: 14236

    
  
Status: RESOLVED → VERIFIED

    
    

    
  
Verified fixed using the 1999092208 build on NT (by using the attached test
case, thanks!).

    
    

    
  
*** Bug 14051 has been marked as a duplicate of this bug. ***

    
  
Status: VERIFIED → REOPENED

    
    

    
  
Bad news -- looks like this is back.  See cpratt's comment under
http://bugzilla.mozilla.org/show_bug.cgi?id=7428.

    
  
Resolution: FIXED → ---
Target Milestone: M11 → M1

    
    

    
  
The test case seems to still work for me using the 1999111008 build under NT.
I'm updating this bug in that build right now... wonder if anything will
change... Any chance the comment in bug 7428 could be due to using an older
build of the browser? (I know, not likely...)

    
  
Target Milestone: M1 → M11

    
    

    
  
I guess the test case isn't perfect. Submitting changes to this bug in the
1999111008 build did change something I swear I didn't change: the Target
Milestone. I'm now setting it back to M11 in 4.7.

    
  
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED

    
    

    
  
Yes, this problem is back - see bug 17519.

Bug 13960 and 17519 are similar symptoms but very different problems.  As such,
I'm closing this one down, but I'm not going to mark it a dup.

    
    

    
  
Going with pollmann on this one. akkana, if I'm wrong (again - sigh), please
reopen. thanks!
Status: RESOLVED → VERIFIED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: