103611 - Autocomplete popup comes up unexpectedly

Status: VERIFIED FIXED

(SeaMonkey :: Location Bar, defect)

Description

[Brian Ryner (not reading)]

There seems to be a regression (within the past 2 weeks or so), where the
Autocomplete popup is coming up unexpectedly when clicking in the urlbar.  Ways
to make it do so are:

1. Single-click anywhere to the right of the url (in the blank space of the
urlbar).  Expected behavior is just to place the cursor at the end of the URL,
but this also drops down the autocomplete popup.

2. Double-click the text in the urlbar.  Expected behavior is to select all text
in the urlbar -- which it does, but it also opens the popup for no apparent reason.

I'll try to track down when this started happening.

Comment 1

[Brian Ryner (not reading)]

This seems to have been caused by [e-mail]'s checkin on 2001/09/28,
log message:

bug 81360
Correct behavior of ResetInputState() for gtk/
Fix memory corruption problem at Resetting IME on GTK
r/sr=blizzard

blizzard, katakai, any ideas?

Comment 2

[jag (Peter Annema)]

Please fix this.

Comment 3

[Masaki Katakai]

Sorry for the regression, I'll try to look into this tomorrow.

Comment 4

[Masaki Katakai]

nsWindow::ResetInputState() in nsWindow.cpp of gtk now
always sends NS_TEXT_EVENT=null to reset the existing
composed text by just single-click. The event seems to
invoke the popup.I'll try to fix the codes not to call
NS_TEXT_EVENT=null when the composed text does not exist.

Comment 5

[jag (Peter Annema)]

Could you somehow filter out double-clicks, instead?

Comment 6

[Masaki Katakai]

Attachment: proposed patch

Comment 7

[Masaki Katakai]

I made a patch and attached. Blizzard, please review.

The problem is that sending NS_TEXT_EVENT=null when
composed text does not exist. We need to avoid the
situation. So I did,

In ResetInputState(),

 xic->IsPreeditComposing()==FALSE, just return;
 
 If ResetIC() returns 0 (XIM server does not return XmbResetIC())
    if style is CALLBAKS (Mozilla draws composed text)
       we need to erase the existing composed text
       so send NS_TEXT_EVENT=null
     else (style is POSITION)
       Mozilla does not draw composed text,
       so we do not have to erase the composed text
 else (if exact length is returned)
    commit the text with NS_TEXT_EVENT


signle-click and double-clicks does not mean in
widget side in this case. We, Widget and IME side
have never consider single-click and double-click.
Widget can get ResetInputMethod() method from upper
level when necessary.

Again, sorry for the regression.

Comment 8

[Brian Ryner (not reading)]

Comment on attachment 52695 [details] [diff] [review]
proposed patch

works for me... assuming the IME input still works correctly (which I can't test), r=bryner

Comment 9

[Christopher Blizzard (:blizzard)]

Comment on attachment 52695 [details] [diff] [review]
proposed patch

sr=blizzard

Comment 10

[Masaki Katakai]

Attachment: revised patch

Comment 11

[Masaki Katakai]

I have found a problem on Solaris environment with
Solaris XIM server. There is no problem on Linux.
It seems that we need to call IMEComposeEnd(nsnull)
when just return from ResetInputState() on Solaris
environment. The difference from the prev patch is
below.

katakai@xymo> diff -c nsWindow.cpp.2 nsWindow.cpp
*** nsWindow.cpp.2      Thu Oct 11 14:17:15 2001
--- nsWindow.cpp        Thu Oct 11 14:17:26 2001
***************
*** 4182,4187 ****
--- 4182,4188 ----

      // if no composed text, should just return
      if(xic->IsPreeditComposing() == PR_FALSE) {
+       IMEComposeEnd(nsnull);
        return NS_OK;
      }

Please review and give r= and sr=.
I'm very sorry for duplicate work.

Comment 12

[Brian Ryner (not reading)]

Comment on attachment 52695 [details] [diff] [review]
proposed patch

marking obsolete

Comment 13

[Brian Ryner (not reading)]

Comment on attachment 53072 [details] [diff] [review]
revised patch

r=bryner

Comment 14

[Christopher Blizzard (:blizzard)]

Comment on attachment 53072 [details] [diff] [review]
revised patch

sr=blizzard

Comment 15

[Masaki Katakai]

Thank you very much for reviews. I've checked in the patch into Trunk.

Comment 16

[R.K.Aa.]

Is any chance to get this into 0.9.5?
This also fixed bug 102282, which broke selection in URL-bar on Linux.

Comment 17

[Masaki Katakai]

Yes, I'll try.

Comment 18

[Masaki Katakai]

Sorry, I missed 0.9.5.

Comment 19

[sairuh (rarely reading bugmail)]

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]