192577 - URL bar drop-down does not collapse on second click on down-arrow

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P4)

Description

[David Bradley]

Windows trunk build, 2/10/03

1. Click on the down arrow in the URL bar
2. Click on it again

Expected result:
Drop down list disappears

Actual result:
Drop down list remains

Comment 1

[Alfonso Martinez]

This problem is also present in the 2003020704 build (win98)

Comment 2

[Benedikt Kantus]

Severity: Minor

Comment 3

[Warner Young]

Also seen on 2003020608.

Comment 4

[Asa Dotzler [:asa]]

Samir, Jag, this one looks like the kind of high visibility UI issue we should
get fixed for 1.3. 

Comment 5

[captainktainer]

Confirming on build 2003021008, WinMe. Minor for my surfing habits- I click
elsewhere anyway.

Comment 6

[Travis Chase]

URL Bar Collapses fine on Build 2003021004 on BeOS

Comment 7

[[e-mail]]

Ah, is this a spinoff from the platform-specific click cancels menu behaviour?
On Linux, when I click the URL bar drop-down, then click somewhere else in
Mozilla, the URL bar drops up, but nothing else happens. But on Windows, when I
click somewhere else, the action happens. Now if the action is to drop down the
URL bar...

Comment 8

[Brendan Eich [:brendan]]

Time's running out for 1.3, but if this is a regression from 1.2 that lots of
people will see, it may be a showstopper.  Anyone have a patch in progress?

/be

Comment 9

[Aaron Leventhal]

my regression

Comment 10

[jag (Peter Annema)]

Aaron: I'm not so sure it is your regression:

I tried finding out when this started, but ran out of nightlies. The best I can
do is somewhere between 1.2 (2002-11-26) and 2002-12-02. If anyone has any
nightly from in between there and could help me reduce the range, that'd be great.

Comment 11

[Aaron Leventhal]

Jag, I'm not sure either.

Autocomplete no longer eats outside clicks because of my patch. Any click
outside the autocomplete popup widget would pop it up. The click on the
dropmarker might be dropping it back down immediately after it gets popped up
because of the outside click.

Comment 12

[jag (Peter Annema)]

Yeah, it seems to be closing and dropping down again. On Win 2k/XP, open the
task manager and place it so that it intersect with the URL bar's dropdown menu.
If you drop it down it'll end up in front of the task manager, if you click it
again you'll see the task manager "shine through" the menu, which suggests it
gets closed and reopened immediately.

Comment 13

[Aaron Leventhal]

I'm working hard on a patch for this, but it looks like it will be too complex
to checkin at this stage of 1.3.

We could back out the fix which caused this regression (so that the autocomplete
widget blocks clicks outside of itself again), but I think that's worse. Worse,
because the autocomplete pops open whenever the user types in the URL bar, and
you then have to click twice to do anything else in the browser.

Comment 14

[Asa Dotzler [:asa]]

Aaron, how's that patch coming? 

Comment 15

[Aaron Leventhal]

Like I said in comment 13, any patch I create to fix this will be too complex
and risky to check in at this point.

For 1.3, we'll have to choose between fixing this and the fact that typing in
the URL bar blocks outside clicks.

Comment 16

[Asa Dotzler [:asa]]

What bug fix regressed this? I'd like to be able to evaluate the tradeoff and
that's difficult without seeing what the old buggy behavior was.

Comment 17

[Jan Varga [:janv]]

asa, I think it was bug 66834

Comment 18

[Aaron Leventhal]

Yes, bug 66834.

Comment 19

[Asa Dotzler [:asa]]

This isn't gathering a lot of dupes with the nightly builds but it seems like a
highly visible regression that might when we release the milestone and I'm not
sure that the fixed behavior is worth it. Should we go back to where we were and
work on a fix for bug 187577 that doesn't break this for 1.4? bug 66835 has
gathered a lot of dupes over the last couple of years but many of them aren't
fixed so that's somewhat misleading. 

Comment 20

[Aaron Leventhal]

I think it was worse when you couldn't click on anything in the browser, just
because a key was typed in the URL bar.

Comment 21

[[e-mail]]

Hmmm... would this be responsible for colourpickerbuttons (appearance prefs)?

Comment 22

[Asa Dotzler [:asa]]

OK, not gonna get fixed for 1.3. The fix is too risky for 1.3final but should be
fixed in the 1.4alpha. We can't let high-visibility regressions like this go
unfixed.

Comment 23

[Alfonso Martinez]

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

Comment 24

[Warner Young]

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

Comment 25

[Alfonso Martinez]

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

Comment 26

[sairuh (rarely reading bugmail)]

cannot repro on linux (rh8.0) or mac os x (10.2.5), but i do see it on win2k. is
this problem limited to win32?

Comment 27

[Julien Pierre]

Reproduced on OS/2 2003043009 .

Comment 28

[Aaron Leventhal]

Attachment: On Windows, wait to rollup on WM_LBUTTONUP, so that a click on the dropmarker doesn't toggle us back open

Ready for testing and review!

Help is appreciated. I am leaving for vacation tomorrow mid day.

Comment 29

[Aaron Leventhal]

Need help getting this reviewed before I leave for vacation tommorrow.

Comment 30

[Aaron Leventhal]

Anyone avaliable to help test this patch? I also want to make sure it doesn't
regress anything on Linux or Mac.

Comment 31

[Aaron Leventhal]

Comment on attachment 122568 [details] [diff] [review]
On Windows, wait to rollup on WM_LBUTTONUP, so that a click on the dropmarker doesn't  toggle us back open

Forgot to mention, this is a new simpler approach -- it is not the scary patch
I had been working on before.

Comment 32

[Dan M]

Comment on attachment 122568 [details] [diff] [review]
On Windows, wait to rollup on WM_LBUTTONUP, so that a click on the dropmarker doesn't  toggle us back open

I can't claim to completely understand everything the patch touches, but the
widget part seems fine, sleepy Ben says the xml part is fine, I've been running
with it on RedHat8, OSX and WinXP and it seems bulletproof. I say check it in.

Comment 33

[Dan M]

Oh, and did I mention:

+          // after the dropmarker does it's toggle.

don't get me all mad by checking in apostrophe grammar like that

Comment 34

[Christopher Aillon (sabbatical, not receiving bugmail)]

Danm, don't get mad.  I fixed that for ya!  And then landed at Asa's request.  I
guess this can be marked fixed, but since it's not my bug, I'll leave it alone.
 Aaron, if there isn't any more work left to be done here, can you close this
when you get a chance?

Comment 35

[Mike Kaply [:mkaply]]

Actually, there needs to be an OS/2 change for this, so please leave open. I'm
looking now.

Comment 36

[Asa Dotzler [:asa]]

Comment on attachment 122568 [details] [diff] [review]
On Windows, wait to rollup on WM_LBUTTONUP, so that a click on the dropmarker doesn't  toggle us back open

I forgot to note approval on the patch. doing that now for historical purposes.
a=asa (on behalf of drivers) for checkin to 1.4b

Comment 37

[Dan M]

I just backed out the change to nsMenuPopupFrame.cpp. See bug 204770. The fix
for this bug seems unaffected by that.

Comment 38

[sairuh (rarely reading bugmail)]

was this checked in already?

Comment 39

[Aaron Leventhal]

checked in a last week

Comment 40

[sairuh (rarely reading bugmail)]

vrfy'd fixed on win2k, 2003.05.15.12 comm build.

Comment 41

[Dan M]

I'm afraid I just backed out all of this patch because of regression bug 204770.
Sorry.

Comment 42

[:deanis74]

I wonder if this was also what was causing Firebird's form autocomplete to not
always close.

Comment 43

[Ben Tremblay]

2003052210 WinME - 2 clicks needed to open 2nd folder?!
Click on Bookmark Toolbar Folder ("A")- Expected: A Drops Down
Result: A Drops Down

Click on a Different Folder ("B")- Expected: A Closes Up; B Drops Down
Result: A Closes Up; B makes no response; jaw drops down

Click a second time on B - Hoped for: Nothing bad
Results: B Drops Down

Comment 44

[Ben Tremblay]

Clicking inside PDF Window does not trigger collapse
* Load PDF in tab
(http://www.research.microsoft.com/~simonpj/papers/excel/excel.pdf is interesting)
* Click on Toolbar Folder (or menu)
* Click within Tab ... UI shrugs

Comment 45

[Samir Gehani]

adt: nsbeta1-

Comment 46

[Jason M. Abels]

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

Comment 47

[Charles Fenwick]

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

Comment 48

[Aaron Leventhal]

Comment on attachment 122568 [details] [diff] [review]
On Windows, wait to rollup on WM_LBUTTONUP, so that a click on the dropmarker doesn't  toggle us back open

This fix was backed out because of problems it created with the personal
toolbar

Comment 49

[Aaron Leventhal]

Attachment: New simple approach to ensure clicking on dropmarker alternates between open/close

Can someone from the community please test this patch? As far as I can tell it
works on the URL bar, but my build has some issues right now so it's hard to
test with XUL comboboxes (menulists). It shouldn't affect the personal toolbar
at all.

Comment 50

[Aaron Leventhal]

Turns out this new patch only fixes 99% of the problem.
If you mouse into the dropmarker, click to open, then hit escape to close the
popup without moving the mouse of the dropmarker, then the next click does not
open the popup again.

However, I think that's kind of a perverse case. We're better with this patch
than without it, unless someone can think of something better.

Comment 51

[[e-mail]]

If only we could roll up the popup after sending the event, then this wouldn't
be a problem...

Comment 52

[Aaron Leventhal]

Attachment: Forgot curly brace in last patch

I've tested on Mac, Windows and Linux and the patch works as expected. Does not
affect dropdowns or personal toolbar.

Comment 53

[Aaron Leventhal]

Comment on attachment 127432 [details] [diff] [review]
Forgot curly brace in last patch

So, do people like this at all, or not?

I haven't heard anything, so I guess this bug isn't so important after all?

Comment 54

[:deanis74]

I think it's a lot better than what we have now, and the fact that it's specific
to autocomplete fields means it's much less prone to regressing other areas than
the last patch.

Comment 55

[Dan M]

Comment on attachment 127432 [details] [diff] [review]
Forgot curly brace in last patch

Yeah, I +ed that first patch, too.

"Well, how does it look now?"

"Looks clear."

r=riddick

Comment 56

[jag (Peter Annema)]

Comment on attachment 127432 [details] [diff] [review]
Forgot curly brace in last patch

Want to get Neil's input on this. In the mouseover handler you have a textbox
variable you don't use.

Comment 57

[Aaron Leventhal]

Attachment: Better patch

Comment 58

[Aaron Leventhal]

Attachment: Alternative approach listens to popupshowing/popuphiding, and works in more cases

This doesn't have the problem of getting confused if the popup closes because
of something other than a click, while the mouse hovers over the dropmarker.

Comment 59

[[e-mail]]

Comment on attachment 127739 [details] [diff] [review]
Alternative approach listens to popupshowing/popuphiding, and works in more cases

Ugh, this is so hacky, I wish I had a Windows build so that I could debug this.

Anyway, I think it would be simpler to defer the remove attribute on the
textbox and use that to test whether to open the popup.

Comment 60

[Aaron Leventhal]

Neil, I'm not actually sure how else to do this. This is definitely better than
what we have now, IMHO.

> Anyway, I think it would be simpler to defer the remove attribute on the
> textbox and use that to test whether to open the popup.

I'm not sure what you mean by this approach. What do you mean by defer? Do you
mean xbl:inherits? 

This is a very difficult bug to fix because of the mozilla/widget architecture.
I'll need more help if anyone actually wants me to fix it.

Comment 61

[[e-mail]]

I mean that you're creating extra properties and stuff, and I think you could
simplify the code by removing the open attribute after 50ms instead of
immediately so that you can check that the attribute before reopening the popup.

Comment 62

[Aaron Leventhal]

Attachment: Simpler patch

Neil, you're so right. Much cleaner that way.

Comment 63

[[e-mail]]

Comment on attachment 127894 [details] [diff] [review]
Simpler patch

A blank line between </implementation> and <handlers> wouldn't go amiss.

Mind you I still have the nagging suspicion that something along the lines of
nsMenuFrame::Execute() is the way to go - although it's not a trivial exercise
:-(

Comment 64

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 127894 [details] [diff] [review]
Simpler patch

>Index: autocomplete.xml
>+        <body><![CDATA[

Linebreak after <body>, please.

>+        ]]></body>

Linebreak before </body>.

>+      </method>
>+    </implementation>

Newline after </implementation>, like Neil said.

>+        setTimeout(this.removeOpenAttribute, 50, this.parentNode);

You can use a timeout of 0ms, I would think.. you just need it to be async.

sr=bzbarsky with those; no need for new patch or anything.

Comment 65

[Asa Dotzler [:asa]]

mozilla1.4 shipped. unsetting blocking1.4 request.

Comment 66

[Mike Kowalski]

Comment on attachment 127894 [details] [diff] [review]
Simpler patch

Landed on trunk, works fine. I don't see any regressions.

Comment 67

[Asa Dotzler [:asa]]

Comment on attachment 127894 [details] [diff] [review]
Simpler patch

aaronl, neil, can one of you get this into the 1.4 branch for us in short
order? We're trying to get 1.4.1 release out the door and this would be a nice
one to finally have fixed.

Comment 68

[Steffen Wilberg]

I still see this problem in Firebird, location bar and search bar.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030808 Mozilla
Firebird/0.6.1+

The original patch fixed this for Firebird as well. This one doesn't.

Comment 69

[Aaron Leventhal]

The same or very similar patch used should be usable in the firebird /toolkit 
directory. Someone should get that in.

Comment 70

[Pham]

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

Comment 71

[Pham]

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

Comment 72

[eric lindvall]

If the problem is with xpfe/components/autocomplete, is this really a firebird
bug? shouldn't Component -> Browser?

Comment 73

[Ben Goodger (use ben at mozilla dot org for email)]

Bringing into .8 for investigation. 

Comment 74

[Pham]

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

Comment 75

[Pham]

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

Comment 76

[Bernard Alleysson]

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

Comment 77

[Ben Goodger (use ben at mozilla dot org for email)]

urg. 

Comment 78

[Mike Connor [:mconnor]]

already moved to 0.9 by ben

Comment 79

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031217 Firebird/0.7+
(daihard; XFT+GTK2; optimized for P4/SSE-2)

Has this been fixed yet? I don't experience this bug at all; the URL drop-down
bar closes up neatly without a problem when I click the arrow a second time.

WRT http://bugzilla.mozilla.org/show_bug.cgi?id=228963 I think someone should
check the code again.

Comment 80

[Will Levine]

This bug has always been Windows only.

Comment 81

[David Whitlock]

(In reply to comment #80)
> This bug has always been Windows only.

and although fixed in Mozilla 1.6, its broken in firefox .8 on Windows.

Comment 82

[Jeff Walden [:Waldo]]

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

Comment 83

[Bradley Chapman (not reading bugmail, still gone but not forever)]

(In reply to comment #80)
> This bug has always been Windows only.

Then I guess it isn't likely to appear on Linux then.

Removing self from CC list.

Comment 84

[Marc Bauer]

if you type in a URL in the bar and press return it will not opened - nothing 
will happen - how often i press return! therefor brwoser is unusable! is this 
related to this bug or should i file a new bug?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 
Firefox/0.8.0+

Comment 85

[Dan M]

That would be a completely unrelated bug. Try a build other than 20040316.

Comment 86

[Bernard Alleysson]

asking blocking 0.9 because it is highly visible, because it was fixed in Mozilla,
because users simply won't understand why the URL bar drop-down doesn't work
like any other combo-boxes

Comment 87

[john]

Attachment: Drop down minimum width wrong:

Hi, check out the screen shot to see how the minimum width of the drop down
box/window needs to be set better...

john.e.boy

Comment 88

[Robert Parenton]

Comment #87 this is not the right bug.  File a new one if you can't find the
right one.

Comment 89

[Mike Connor [:mconnor]]

not a 0.9 blocker.  It should be fixed before 1.0, but its not going to kill
anyone if it lasts one more milestone.

Comment 90

[Asa Dotzler [:asa]]

possibly related to bug 240095?

Comment 91

[Wolf [:wolf]]

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

Comment 92

[Norbert]

Please don't forget to fix this also for the search bar, not only for the URL bar!

Comment 93

[Worcester12345]

(In reply to comment #92)
> Please don't forget to fix this also for the search bar, not only for the URL bar!

Seconded!

Comment 94

[Grey Nicholson (they/them)]

(In reply to comment #93)
> (In reply to comment #92)
> > Please don't forget to fix this also for the search bar, not only for the
URL bar!
> 
> Seconded!

There's no drop-down on the search bar - the search engine selector isn't
supposed to be a native drop-down like the location bar, so it needn't behave
like a native drop-down.

Comment 95

[Norbert]

(In reply to comment #94)

> There's no drop-down on the search bar - the search engine selector isn't
> supposed to be a native drop-down like the location bar, so it needn't behave
> like a native drop-down.

Nice argument. Where would be the problem if the searchbar also closes with a
second click? It would just be more intuitive.

Comment 96

[Grey Nicholson (they/them)]

(In reply to comment #95)
> (In reply to comment #94)
> 
> > There's no drop-down on the search bar - the search engine selector isn't
> > supposed to be a native drop-down like the location bar, so it needn't behave
> > like a native drop-down.
> 
> Nice argument. Where would be the problem if the searchbar also closes with a
> second click? It would just be more intuitive.

There'd be no problem at all if it closed with a second click; it probably is
more intuitive that way.

But I think that'd be a separate enhancement, rather than a bug in emulating the
OS. You could file an enhancement bug for that (unless of course one already
exists). I don't think it should become part of this bug - it probably wouldn't
block 1.0.

Comment 97

[Norbert]

(In reply to comment #96)

> But I think that'd be a separate enhancement, rather than a bug in emulating the
> OS. You could file an enhancement bug for that (unless of course one already
> exists). I don't think it should become part of this bug - it probably wouldn't
> block 1.0.

I have submitted bug 252917 therefore.

Comment 98

[Asa Dotzler [:asa]]

If this isn't going to be fixed, at a bare minimum, maybe we can make it not flash.

Comment 99

[Asa Dotzler [:asa]]

Aaron, can you help us with this for Firefox? This is a fairly visible glitch in
our primary UI and if it was important enough to hold SeaMonkey releases for, I
think we ought to get it into our Firefox 1.0 release.

Comment 100

[Aaron Leventhal]

Attachment: Close to the same fix for Firefox as for Seamonkey

Comment 101

[Mike Connor [:mconnor]]

Comment on attachment 156358 [details] [diff] [review]
Close to the same fix for Firefox as for Seamonkey

looks good to me

Comment 102

[Aaron Leventhal]

Comment on attachment 156358 [details] [diff] [review]
Close to the same fix for Firefox as for Seamonkey

No sr= needed

Comment 103

[Asa Dotzler [:asa]]

Comment on attachment 156358 [details] [diff] [review]
Close to the same fix for Firefox as for Seamonkey

Yay!  a=asa for aviary checkin. Thanks aaronl.

Comment 104

[Aaron Leventhal]

Firefox trunk checkin:
Checking in autocomplete.xml;
/cvsroot/mozilla/toolkit/content/widgets/autocomplete.xml,v  <--  autocomplete.xml
new revision: 1.29; previous revision: 1.28
done

Firefox aviary branch checkin:
Checking in autocomplete.xml;
/cvsroot/mozilla/toolkit/content/widgets/autocomplete.xml,v  <--  autocomplete.xml
new revision: 1.23.6.4; previous revision: 1.23.6.3
done

Comment 105

[Dave Wolovich]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040811
Firefox/0.9.1+

I still see the URL bar persisting when clicking on it a second time.  

Comment 106

[Dave Wolovich]

Ignore comment #105 above.  I downloaded the latest branch build from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/ and even
though the file date was marked as 2004-08-19 it downloaded the 2004-08-11
build.  Perhaps a bad symlink. 

Nonetheless, I'm now running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.2) Gecko/20040819 Firefox/0.9.1+ and all is good.  My apologies. 

Comment 107

[:deanis74]

verified based on above comment

Comment 108

[Ryan Polk (Quark)]

There are still some problems with this.

Flashing:
1) Click on text area of search-bar (needed for focus change).
2) Click on Location Bar arrow.  It flashes and disappears.
3) Click on Location Bar again, it behaves as intended as if this is first click.

Unresponsive 2nd Click:
1) Click on Location Bar to give it focus.
2) Click on Location Bar arrow.  Menu appears as normal.
3) Click on arrow again, nothing happens.
4) Clicks from this point on work normally.

The 2nd problem can be produced in other ways, but I haven't fully figured it
out.  Should these be forked to new bug reports?

Comment 109

[Grey Nicholson (they/them)]

(In reply to comment #108)
> There are still some problems with this.
> 
> Flashing:
> 1) Click on text area of search-bar (needed for focus change).
> 2) Click on Location Bar arrow.  It flashes and disappears.
> 3) Click on Location Bar again, it behaves as intended as if this is first click.
> 
> Unresponsive 2nd Click:
> 1) Click on Location Bar to give it focus.
> 2) Click on Location Bar arrow.  Menu appears as normal.
> 3) Click on arrow again, nothing happens.
> 4) Clicks from this point on work normally.
> 
> The 2nd problem can be produced in other ways, but I haven't fully figured it
> out.  Should these be forked to new bug reports?

I can (sort of) reproduce both, given the following changes:

Flashing:
1) Click on drop-down engine selector doohickey.

Unresponsive 2nd Click:
0) Open a new tab or switch to a tab where you've never selected text in the
location bar (i.e. seems to work only once per tab)
1) Double-click text in the location bar to select it

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.2) Gecko/20040818

Comment 110

[Graham Adams]

> 
> I can (sort of) reproduce both, given the following changes:
> 
> Flashing:
> 1) Click on drop-down engine selector doohickey.
> 
> Unresponsive 2nd Click:
> 0) Open a new tab or switch to a tab where you've never selected text in the
> location bar (i.e. seems to work only once per tab)
> 1) Double-click text in the location bar to select it
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.2) Gecko/20040818

The flashing problem is bug #240095
I can't reproduce the 2nd click problem