Closed Bug 225893 Opened 21 years ago Closed 21 years ago

Autocomplete selects first address in list when user attempts to scroll down.

Categories

(SeaMonkey :: Autocomplete, defect)

Product:
SeaMonkey
Component:
Autocomplete
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: hstark, Assigned: neil)

References

Details

Attachments

(1 file)

Proposed patch
837 bytes, patch
asa
: review+
mscott
: superreview+
asa
: approval1.6+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031112
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031112

Autocomplete inappropriately selects first address in list when user attempts to
scroll down to find the needed address. It was working correctly in M1.5

Reproducible: Always

Steps to Reproduce:
1.Open Compose window
2.Type a few letters in "To" in order to find the needed address amoung a long
list of addresses. 
3.Dialogue opens with the first few of the appropriate addresses. Assume that
there are more addresses than appears in the list.
4.Try to scroll down to appropriate address from those below and not showing.

Actual Results:  
Autocomplete selects the first name on the list and closes. Get the same result
when using "Cc" or "Bc" or the rest of the choices.

Expected Results:  
Scroll down list to allow user to pick proper address.
Reproduce on Linux trunk build.
Note that this bug only affects mouse scrolling; keyboard scrolling is OK.
I was able to duplicate this bug in the Open Location dialog too.
Assignee: sspitzer → hewitt
Status: UNCONFIRMED → NEW
Component: Composition → XP Apps: Autocomplete
Ever confirmed: true
OS: Windows 98 → All
Product: MailNews → Browser
QA Contact: esther → claudius
Hardware: PC → All
Just checked keyboard scrolling works. It never occured to me to try it. Force
of habit I guess. Sorry
OK, so what's happening is that these days scrollbars now focus their owner, or
something - unfortunately autocomplete isn't expecting the focus to change when
you click on its scrollbar. roc, can you confirm that please?
I would if I could, but I don't know how.
Flags: blocking1.6?
Flags: blocking1.6? → blocking1.6+
See the mail version of this bug: 226804 for auto complete in mail compose.
I've got a hunch this is "fallout" from bug 215928. Basically autocomplete
cancels when the input loses focus, and trees like to take focus, so an event
handler was added to catch mousedown events on the tree to prevent the tree from
grabbing focus from the input. I've got two options here: 1) Use a capturing
event handler (which I implemented in xbl instead of using an attribute for
extra brownie points) or 2) Make it so that autocomplete trees don't care about
focus.
Attached patch Proposed patch — — Splinter Review 

    
    

    
  
Comment on attachment 136901 [details] [diff] [review]
Proposed patch

Patch 2 caused a regression , so I couldn't use it :-/

        Attachment #136901 -
        Attachment description: Patch 1 → Proposed patch

        Attachment #136901 -
        Flags: superreview?(mscott)

        Attachment #136901 -
        Flags: review?(bryner)

    
  

        Attachment #136901 -
        Flags: superreview?(mscott) → superreview+

    
    

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

    
    

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

    
    

    
  
brian, can you catch the review on this?  if its going to make 1.6 need to do it
quickly
Assignee: hewitt → neil.parkwaycc.co.uk

    
    

    
  
The mousedown event is what triggers the bug, so I tried deleting
this line from xpfe/global/resources/content/bindings/scrollbar.xml:

<handler event="mousedown" action="event.preventBubble();"/>

and the bug is gone.  Am I re-introducing a bug somewhere else by
doing this?  I haven't spotted anything yet...


    
    

    
  
I like Neil's fix. Thanks Neil!

    
    

    
  
Comment on attachment 136901 [details] [diff] [review]
Proposed patch

r=ben@mozilla.org

This is good because generally should avoid using event handlers on <content>
because if the user specifies a mousedown handler it'll clobber the one that
was set in the XBL binding, which is what I bet was happening here.

        Attachment #136901 -
        Flags: review?(bryner)

    
    

    
  
Comment on attachment 136901 [details] [diff] [review]
Proposed patch

a=asa (on behalf of drivers) for checkin to Mozilla 1.6

        Attachment #136901 -
        Flags: review+

        Attachment #136901 -
        Flags: approval1.6+

    
    

    
  
Fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Ah.. YOu are exactly right!  1.6 has it fixed.  I had looked and had not
realized that there was a new version.  I wish Mozilla had a more obvious rlease
numbering scheme!  Bravo on the fix!

    
    

    
  
*** Bug 234097 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite

    
  
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: