287996 - full URL not displayed after autocomplete URL loaded and switching tabs

Status: RESOLVED FIXED

(SeaMonkey :: Location Bar, defect)

Description

[Andrew Schultz]

Callek noticed this...
With linux trunk build 2005032705, if I
0. have more than one tab open
1. type a partial URL
2. select one of the auto-complete URLs
3. hit enter
4. switch to a different tab
5. switch back

Actual results:
only the part of the URL I typed in step 1 is display.  Once the page starts
actually loading, the full URL is displayed again

Expected results:
The full URL should be displayed as it was between steps 3 and 4.

This regressed between linux trunk 2005021505 and 2005021613.  Could bug 272002
have caused this?

Comment 1

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050326

5a. switching back quickly loads partial URL, with .com appended.
5b. switching back a bit slower shows the partial URL, replaced by the full when
loading has finished.

saw behaviour as described, typeing 'the' I selected theinquirer.net, hit
return, switched to another tab, and back, saw 'the' in the URL bar until the
page was loaded. Sometimes however, if I switched back very quick, the.com was
loaded. 
Also tested with hei, showing lots of entires for heise.de, could also load hei.com.

Comment 2

[Justin Wood (:Callek)]

Well slight correction, I noticed it with windows XP, asked you to verify for me
with your build (which is linux), so OS-All seems appropriate.  Thank you for
filing.

Comment 3

[Asa Dotzler [:asa]]

bryner, can you have a look at this please?

Comment 4

[Caleb]

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

Comment 5

[Chase Phillips]

Per Deer Park meeting mconnor and asa will investigate.  Maybe doesn't occur in
Firefox.

Comment 6

[Caleb]

(In reply to comment #5)
> Per Deer Park meeting mconnor and asa will investigate.  Maybe doesn't occur in
> Firefox.

It happens in Firefox alright.. Look at bug 295224 (which is a dupe of this)
that I've filed.

Comment 7

[Asa Dotzler [:asa]]

->bryner. Brian, if you can't help us here, can you suggest a better owner? 

Comment 8

[Adam Guthrie]

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

Comment 9

[Ed Lee :Mardak]

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

Comment 10

[Mike Connor [:mconnor]]

This appears to be fixed, actually as of 06/14, I think this is why I thought it
was already fixed in Firefox.

Duping since this morphed to a firefox bug, please file a seamonkey bug if this
still exists there.

*** This bug has been marked as a duplicate of 227826 ***

Comment 11

[Andrew Schultz]

this doesn't seem to be in Firefox product to me

reopening

Comment 12

[Ed Lee :Mardak]

I can still trigger the problem using a 1.8branch build.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050819
Firefox/1.0+

Try using the instructions from the other bug report.

Steps to reproduce:
1. Load the provided url in a tab (http://agadak.net/10sec.php)
2. Open a new tab and type "aga" to trigger autocomplete
3. Select the entry for the same page
4. Switch to a different tab then back to the tab used for step 3 (before it
finishes loading)

Actual: "aga" is shown in the location bar
Expected: Selected entry should be in the location bar

It works fine in Firefox 1.0.6, and the trunk builds work until 20050215.
Versions from 20050216 up to the latest (20050807) are not working correctly.
Tested on mac and windows.

Comment 13

[Andrew Schultz]

backing out bug 272002 fixed this bug xif 

Comment 14

[Brian Ryner (not reading)]

Attachment: patch

This patch makes us treat user-initiated autocomplete the same as the user
typing in the field, that is, dispatch an oninput event.  To make this work I
had to fix the event code to correctly handle a script-created input event.

Comment 15

[Mike Connor [:mconnor]]

Comment on attachment 193411 [details] [diff] [review]
patch

r=me on the toolkit/xpfe bits, the layout/content bits look ok, but jst can
r+sr those as appropriate.

Comment 16

[Johnny Stenback (:jst)]

Comment on attachment 193411 [details] [diff] [review]
patch

sr=jst

Comment 17

[Brian Ryner (not reading)]

Comment on attachment 193411 [details] [diff] [review]
patch

requesting approval... note that this bug should probably still be marked as
blocking1.8b4+, since it was only minused when it was incorrectly marked as a
dup.

Comment 18

[Brian Ryner (not reading)]

checked in on trunk and branch

Comment 19

[tor]

This checkin caused the regression in bug 305591.

Comment 20

[Scott MacGregor]

I'm seeing some pretty whacky thunderbird autocomplete regressions in this
morning's branch builds that was not there in yesterdays's build. This patch
looks suspicious :). For starters, the auto complete popup won't stay open so
you can't select an autocomplete match at all. Second, I keep ending up with
resutls like
Scott >> Scott MacGregor <[e-mail]>

after hitting enter to accept an autocomplete result.

I'll get a bug started.

Comment 21

[Scott MacGregor]

I filed Bug #305654 to track broken auto complete in mail caused by this bug.

Comment 22

[Scott MacGregor]

I've verified that removing the firing of the oninput event inside setTextValue
makes autocomplete work again. i.e. removing:

          var evt = document.createEvent("UIEvents");
          evt.initUIEvent("input", true, false, window, 0);
          var oldIgnoreInput = this.mIgnoreInputEvent;
          this.mIgnoreInputEvent = true;
          this.dispatchEvent(evt);
          this.mIgnoreInputEvent = oldIgnoreInput;

if browser autocomplete needs this, maybe it should set an attribute on the
autocomplete widget for simulating oninput events which it can explicitly ask
for. setTextValue could then check the value of that field before executing this
new code. 

Comment 23

[Brian Ryner (not reading)]

Shouldn't be necessary; this is supposed to just restore the pre-272002
behavior.  I'll take a look to see why it's not working as it should.

(In reply to comment #22)
> if browser autocomplete needs this, maybe it should set an attribute on the
> autocomplete widget for simulating oninput events which it can explicitly ask
> for. setTextValue could then check the value of that field before executing this
> new code. 
> 
>