290878 - Address Autocomplete don't work, always first entry was taken (regression)

Status: VERIFIED FIXED

(Core :: Web Painting, defect)

Description

[Tobias Fischer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050418 Mnenhy/0.7.2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050418 Mnenhy/0.7.2.0

Starting with Seamonkey Build 2005041805 the E-Mail Address Autocomplete is broken. 

When starting to type the first letters, the list of addresses shows up, but I
can't choose an suggestion without the first one. 

Everytime the first Entry will be taken for addressing at To: Field, and also
the typing. Typing first three letters addressing looks like: "tobias Fischer
<[e-mail]>", not "Tobias..."

Last known good Build was 2005041710 for me, next tested is 2005041805 which was
regressed.

Reproducible: Always

Steps to Reproduce:
1. Compose new Message
2. Start typing in To: Field for addressing
3. Try to choose *not* the first suggestion

Actual Results:  
Every time the first shown Entry is taken from Autocomplete Suggestion-List.

Expected Results:  
Be able to choose one Address from List free.

This regressed between 2005-04-17 10:00 and 2005-04-18 05:00, add Bonsai Query:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=day&mindate=2005-04-17+10%3A00%3A00&maxdate=2005-04-18+05%3A00%3A00&cvsroot=%2Fcvsroot

Comment 1

[Tobias Fischer]

Sorry, I have paste a wrong Querey. Rüdiger Lahl <[e-mail]>
has told me, that this was broken in 2005041803, so here is the right Query:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-17+10%3A00%3A00&maxdate=2005-04-18+03%3A00%3A00&cvsroot=%2Fcvsroot

Comment 2

[Frank Wein [:mcsmurf]]

bz: This might be a possible regression from Bug 290494. When i hover over a
autocomplete entry, i get this in JS Console (for every mousemove):
JavaScript error: chrome://global/content/autocomplete.xml, line 1544: col.value
has no properties

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed patch

This is the "simple" fix.  The other approach is to just use event.client* here
and to make the tree code try to figure out whether it's inside a popup and if
so try to adjust for the bogosity.  But really, we should fix bug 291083.

Comment 4

[[e-mail]]

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

You mean, not only are event client coordinates wrong for popups, but box
object coordinates are wrong for popups in lists?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> but box object coordinates are wrong for popups in lists?

You mean the x/y coordinates of a box object?  Those look like someone
copy/pasted the offset* code from HTML elements at some point.  I don't know
that they're "wrong", since I can't tell what they're trying to be (no
documentation), but they more or less correctly return the offset of the
padding-box of the thing the box object is for from the padding-box of the
document element, under the assumption that all scrollable things are scrolled
to (0,0).

I'm not quite sure what you mean by "popups in lists"....

Comment 6

[[e-mail]]

Well, the only difference between compose autocomplete and browser autocomplete
(which still works) is that the compose widget is inside a listbox, so I assume
that's affecting some set of coordinates somehow, and wondering why.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Oh, that sort of list.  Possible.  Not sure. In any case, box object coordinates
are not client coordinates.  Should they be?  If so, I'll file a bug on that.

Comment 8

[[e-mail]]

(In reply to comment #7)
>In any case, box object coordinates are not client coordinates. Should they be?
I'd hate to think what else they could be, so I made some measurements.
navigator       window         textbox         tree
client          (0, 0)         (299, 35) ?     (298, 57)
screen          (6, 22)        (303, 55)       (304, 79)
I don't understand where this client/screen discrepancy arises in the textbox.
compose         window         textbox         tree
client          (0, 0)         (128, 101)      (415, 102) !
screen          (6, 22)        (134, 123)      (135, 140)
What effect does overflow have on the HTML offsetX/Y properties?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> I don't understand where this client/screen discrepancy arises in the textbox.

"client" measures from padding box to padding box; screen gives the screen
position of the border box (this is all for box object).

> What effect does overflow have on the HTML offsetX/Y properties?

Absolutely none.  offset* is computed as if all scrollable stuff were scrolled
to 0,0.

Comment 10

[[e-mail]]

(In reply to comment #9)
>>What effect does overflow have on the HTML offsetX/Y properties?
>offset* is computed as if all scrollable stuff were scrolled to 0,0.
Not very useful for hit-testing in listboxes then (popup bug notwithstanding).

Comment 11

[Boris Zbarsky [:bzbarsky]]

Yes, that was exactly my point.  Again, should I file a bug on that?  Looking at
the tree, people are comparing boxObject.x to event.clientX and such...

Comment 12

[Ruediger Lahl]

(In reply to comment #0)

> Expected Results:  
> Be able to choose one Address from List free.

It seems, that this is no problem, if you do the selection with cursdown/up keys
on the keyboard. IMHO the selection only fails, if you use the mouse.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yes, we're well aware.  I suggest you read the patch.

Comment 14

[[e-mail]]

Yes, I'd like to be able to compare events with box objects, please.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Bug 291351 filed.

Comment 16

[R.K.Aa.]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

requesting approval for yet another event coord regression fix...

Comment 18

[William T Byron Jr.]

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

Comment 19

[Asa Dotzler [:asa]]

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

a=asa

Comment 20

[Boris Zbarsky [:bzbarsky]]

Fixed

Comment 21

[Tobias Fischer]

I have tested this several Times with CREATURE-Tinderbox-Build 2005042420 and
Autocomplete and choosing an Address with Mouse works fine (almost for me). 

Because that I mark this as Verified=Fixed now.

Comment 22

[Mike Cowperthwaite]

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

Comment 23

[Daniel]

I just don't understand why the [Bug 278398] (address typed gets replaced with
first email address from dropdown list after Tab is pressed) has been marked as
a duplicate of this bug (290878)??? It is much older than this one, so
semantically correct this bug is duplicate of 278398 bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=278398

Comment 24

[Anne (:annevk)]

Not when the newer bug is fixed.

Comment 25

[Michael Graubart]

Actually the version of this bug that I reported is slightly different again.
What I observe is that if I type the beginning of a name into the address pane
of 'Compose' in 'Mail/News', all the addresses connected with that
name-beginning do appear on successive lines. But it is at that point that the
bug strikes: if I click on any of them, it is always the first one that is
entered. If, on the other hand, I use the down-arrow on the keyboard to scroll
down the successive addresses and stop at the desired one, I can use 'Enter' on
the keyboard to enter that address.