full URL not displayed after autocomplete URL loaded and switching tabs

RESOLVED FIXED

Status

SeaMonkey
Location Bar
--
minor
RESOLVED FIXED
13 years ago
9 years ago

People

(Reporter: Andrew Schultz, Assigned: Brian Ryner (not reading))

Tracking

({fixed1.8, regression})

Trunk
x86
All
fixed1.8, regression
Dependency tree / graph
Bug Flags:
blocking1.8b2 -
blocking1.8b3 -
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [no l10n impact])

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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

13 years ago
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

13 years ago
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.
Flags: blocking1.8b2?

Comment 3

13 years ago
bryner, can you have a look at this please?
Flags: blocking1.8b3+
Flags: blocking1.8b2?
Flags: blocking1.8b2-

Comment 4

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

Updated

13 years ago
QA Contact: asa

Comment 5

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

Comment 6

13 years ago
(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

13 years ago
->bryner. Brian, if you can't help us here, can you suggest a better owner? 
Assignee: location-bar → bryner

Updated

13 years ago
Flags: blocking1.8b4+
Flags: blocking1.8b3-
Flags: blocking1.8b3+

Comment 8

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

Updated

13 years ago
Whiteboard: [no l10n impact]

Comment 9

13 years ago
*** Bug 303870 has been marked as a duplicate of this bug. ***
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 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Flags: blocking1.8b4+ → blocking1.8b4-
Resolution: --- → DUPLICATE
(Reporter)

Comment 11

13 years ago
this doesn't seem to be in Firefox product to me

reopening
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Updated

13 years ago
Assignee: bryner → location-bar
Status: REOPENED → NEW
QA Contact: asa

Comment 12

13 years ago
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.
(Reporter)

Comment 13

13 years ago
backing out bug 272002 fixed this bug xif 
Depends on: 272002
(Assignee)

Comment 14

13 years ago
Created attachment 193411 [details] [diff] [review]
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.
Assignee: location-bar → bryner
Status: NEW → ASSIGNED
Attachment #193411 - Flags: superreview?(jst)
Attachment #193411 - Flags: review?(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.
Attachment #193411 - Flags: review?(mconnor) → review+
Comment on attachment 193411 [details] [diff] [review]
patch

sr=jst
Attachment #193411 - Flags: superreview?(jst) → superreview+
(Assignee)

Comment 17

13 years ago
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.
Attachment #193411 - Flags: approval1.8b4?

Updated

13 years ago
Flags: blocking1.8b4- → blocking1.8b4+

Updated

13 years ago
Attachment #193411 - Flags: approval1.8b4? → approval1.8b4+
(Assignee)

Comment 18

13 years ago
checked in on trunk and branch
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago13 years ago
Keywords: fixed1.8
Resolution: --- → FIXED

Comment 19

13 years ago
This checkin caused the regression in bug 305591.

Comment 20

13 years ago
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 <mscott@mozilla.org>

after hitting enter to accept an autocomplete result.

I'll get a bug started.

Updated

13 years ago
Depends on: 305654

Comment 21

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

Comment 22

13 years ago
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. 

(Assignee)

Comment 23

13 years ago
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. 
> 
> 

(Reporter)

Updated

12 years ago
Blocks: 303866
Product: Core → SeaMonkey

Updated

9 years ago
QA Contact: location-bar
You need to log in before you can comment on or make changes to this bug.