URL bar swaps characters typed



Location Bar
17 years ago
10 years ago


(Reporter: Christian Reis, Assigned: rubydoo123)


Firefox Tracking Flags

(Not tracked)




(1 attachment)



17 years ago
I can't find the steps to reproduce this, but it is happening occasionally with
the build I'm using (2001060811) and I've seen it with other builds this week.
Basically the URL bar goes bezerk and every character I type after the first
(important: the first character is okay) is swapped. I've typed in the following
set and pasted here the results:




It does _NOT_ happen when pasting the text in the X clipboard with the mouse;
only when typing into the URL bar itself. I've provided a screenshot of mozilla
when I type in 'www.mozillazine.org' and press enter here (the proxy error shows
that it's not just a display error, but a real char-swap error).

Comment 1

17 years ago
Havent see this, apart from the @ -> '
Can be related to reopened bug 61439
Summary: URL bar swaps characters typed → URL bar swaps characters typed

Comment 2

17 years ago
I should add this is XFree 4.0.3, and I've got the MSTTF family installed
locally (actually, served through NFS, though it's probably irrelevant).

Comment 3

17 years ago
sounds like an editor bug to me
reassigning to beppe
Assignee: alecf → beppe

Comment 4

17 years ago
Do you see this problem only when you type in the urlbar or do you also see it 
when you type in other places such as form elements or other UI locations like 
the open location dialog?

Comment 5

17 years ago
Only when using the URLBar. It happens exactly when the little completion popup
shows up, but turning off completion does _not_ fix the problem. 

All other form elements are fine by my experience (but since it's hard to
trigger, I might not be testing them as hard as the URLBar): text, textarea work

Comment 6

17 years ago
I've seen this kind of garbage show up when the content tree gets out of sync 
with the frame tree ... a sign that reflows are not happening or are being 
supressed by parent frames.

Without reproduceable steps or a test case, i can't back that up though.

Cc'ing waterson and attinasi.

Comment 7

17 years ago
Oh. This might be important, and I just noticed it:

Characters that have accents like á (á if it renders bad) and õ
(õ) _work fine_ when the problem is active. This means that although c
normally becomes ¢, I can type ç (ç) just fine.

It's probably related to handling of extended ASCII (Latin-1, etc) chars. I'll
test further here.

Comment 8

17 years ago
I think this can be reproduced by the following steps (it _does_ work here, but
keep in mind my keyboard is configured to use Xmodmap.us+, which I'm attaching
here, so you'll have to load it and use the deadkeys - anyone not know how
deadkeys work?)

1. Start Browser
2. type www.async.com.br/~ # at this point the characters are broken.

The full URL I was trying to reach is www.async.com.br/~unicastelo/

I've erased my profile and restarted and I still see the bug.

Another thing worth noting is that if I unfocus the window and focus back the
_first_ character I type is okay again and then the garbage comes back.

Comment 9

17 years ago
Created attachment 37917 [details]
Xmodmap for US keyboard with deadkeys

Comment 10

17 years ago
adding Frank

Comment 11

17 years ago
this is a side effect of the (2nd try) fix for bug 61439.
As a temporary workaround edit unix.js


  pref("keyboard.mode_switch.enable_workaround", true);


  pref("keyboard.mode_switch.enable_workaround", false);

*** This bug has been marked as a duplicate of 61439 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 12

17 years ago
This is fixed in build 2001062306! No file text editing needed!
mass-verifying Duplicate bugs which haven't changed since 2001.12.31.

set your search string in mail to "CitizenGKar" to filter out these messages.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.