Closed Bug 192577 Opened 22 years ago Closed 20 years ago

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

Categories

(Firefox :: Address Bar, defect, P4)

Product:
Firefox
Component:
Address Bar
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox0.9

People

(Reporter: dbradley, Assigned: aaronlev)

References

Details

(Keywords: fixed-aviary1.0, regression)

Attachments

(3 files, 5 obsolete files)

Simpler patch
1.48 KB, patch
bzbarsky
: superreview+
Details | Diff | Splinter Review
Drop down minimum width wrong:
47.93 KB, image/png
Details
Close to the same fix for Firefox as for Seamonkey
1.26 KB, patch
mconnor
: review+
asa
: approval-aviary+
Details | Diff | Splinter Review 
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
This problem is also present in the 2003020704 build (win98)
Severity: Minor
Severity: normal → minor
Also seen on 2003020608.
Flags: blocking1.3?
Keywords: nsbeta1
Samir, Jag, this one looks like the kind of high visibility UI issue we should
get fixed for 1.3.
Assignee: hewitt → jaggernaut
Flags: blocking1.3? → blocking1.3+
Confirming on build 2003021008, WinMe. Minor for my surfing habits- I click
elsewhere anyway.
URL Bar Collapses fine on Build 2003021004 on BeOS
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...
Keywords: regression
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
my regression
Assignee: jaggernaut → aaronl
Severity: minor → normal
Priority: -- → P1
Target Milestone: --- → mozilla1.3final
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.
Severity: normal → minor
Priority: P1 → --
Target Milestone: mozilla1.3final → ---
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.
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.
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.
Aaron, how's that patch coming? 
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.
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.
asa, I think it was bug 66834
Yes, bug 66834.
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. 
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.
Hmmm... would this be responsible for colourpickerbuttons (appearance prefs)?
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.
Flags: blocking1.4a+
Flags: blocking1.3-
Flags: blocking1.3+
*** Bug 196754 has been marked as a duplicate of this bug. ***
*** Bug 197309 has been marked as a duplicate of this bug. ***
*** Bug 194847 has been marked as a duplicate of this bug. ***
Flags: blocking1.4a+ → blocking1.4a-
Flags: blocking1.4b?
Flags: blocking1.4b? → blocking1.4b+
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?
Keywords: pp
QA Contact: claudius → sairuh
Reproduced on OS/2 2003043009 .
Ready for testing and review!

Help is appreciated. I am leaving for vacation tomorrow mid day.
Need help getting this reviewed before I leave for vacation tommorrow.
Attachment #122568 - Flags: superreview?(bryner)
Attachment #122568 - Flags: review?(danm)
Anyone avaliable to help test this patch? I also want to make sure it doesn't
regress anything on Linux or Mac.
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 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.
Attachment #122568 - Flags: review?(danm) → review+
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
Attachment #122568 - Flags: superreview?(bryner) → superreview+
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?
Actually, there needs to be an OS/2 change for this, so please leave open. I'm
looking now.
Component: URL Bar → GFX
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
Attachment #122568 - Flags: approval1.4b+
I just backed out the change to nsMenuPopupFrame.cpp. See bug 204770. The fix
for this bug seems unaffected by that.
was this checked in already?
checked in a last week
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
vrfy'd fixed on win2k, 2003.05.15.12 comm build.
Status: RESOLVED → VERIFIED
I'm afraid I just backed out all of this patch because of regression bug 204770.
Sorry.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Flags: blocking1.4?
I wonder if this was also what was causing Firebird's form autocomplete to not
always close.
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

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
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Blocks: 202646
*** Bug 202646 has been marked as a duplicate of this bug. ***
No longer blocks: 202646
*** Bug 211902 has been marked as a duplicate of this bug. ***
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
Attachment #122568 - Attachment is obsolete: true
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.
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.
Attachment #127337 - Flags: superreview?(jaggernaut)
Attachment #127337 - Flags: review?(danm)
If only we could roll up the popup after sending the event, then this wouldn't
be a problem...
Attached patch Forgot curly brace in last patch (obsolete) — — Splinter Review 
I've tested on Mac, Windows and Linux and the patch works as expected. Does not
affect dropdowns or personal toolbar.
Attachment #127337 - Attachment is obsolete: true
Attachment #127337 - Flags: superreview?(jaggernaut)
Attachment #127337 - Flags: review?(danm)
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?
Attachment #127432 - Flags: superreview?(jaggernaut)
Attachment #127432 - Flags: review?(danm)
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 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
Attachment #127432 - Flags: review?(danm) → review+
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.
Attachment #127432 - Flags: review+ → review?(neil.parkwaycc.co.uk)
Attached patch Better patch (obsolete) — — Splinter Review 

        Attachment #127432 -
        Attachment is obsolete: true

    
  

        Attachment #127719 -
        Flags: review?(neil.parkwaycc.co.uk)

    
  

        Attachment #127432 -
        Flags: superreview?(jaggernaut)

        Attachment #127432 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  


  
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.

    
  

        Attachment #127739 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  
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.

        Attachment #127739 -
        Flags: review?(neil.parkwaycc.co.uk) → review-

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Simpler patch
        — 
          — Splinter Review
      

    


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

        Attachment #127719 -
        Attachment is obsolete: true

        Attachment #127739 -
        Attachment is obsolete: true

    
  

        Attachment #127894 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  
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
:-(

        Attachment #127894 -
        Flags: review?(neil.parkwaycc.co.uk) → review+

    
  

        Attachment #127894 -
        Flags: superreview?(jaggernaut)

    
  

        Attachment #127719 -
        Flags: review?(neil.parkwaycc.co.uk)

    
  

        Attachment #127894 -
        Flags: superreview?(jaggernaut) → superreview?(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.

        Attachment #127894 -
        Flags: superreview?(bzbarsky) → superreview+

    
  
Flags: blocking1.4.x?

    
    

    
  
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4?

    
  
Flags: blocking1.4.x? → blocking1.4.x+

    
    

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

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

        Attachment #127894 -
        Flags: approval1.4.x?

    
    

    
  
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.

        Attachment #127894 -
        Flags: approval1.4.x? → approval1.4.x+

    
  
Keywords: fixed1.4.1

    
    

    
  
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.

    
    

    
  
The same or very similar patch used should be usable in the firebird /toolkit 
directory. Someone should get that in.
Assignee: aaronl → hewitt
Status: REOPENED → NEW
Component: GFX → Autocomplete
Product: Browser → Firebird
QA Contact: sairuh → davidpjames
Target Milestone: --- → After Firebird 1.0
Version: Trunk → unspecified

    
    

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

    
    

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

    
    

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

    
  
Summary: URL bar doesn't collapse → URL bar drop-down does not collapse on second click on down-arrow

    
    

    
  
Bringing into .8 for investigation. 
Assignee: hewitt → bugs
Target Milestone: After Firebird 1.0 → Firebird0.8

    
    

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

    
    

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

    
  
Blocks: 224532

    
    

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

    
    

    
  
urg. 
Status: NEW → ASSIGNED
Target Milestone: Firebird0.8 → Firebird0.9

    
  
Flags: blocking0.8?

    
    

    
  
already moved to 0.9 by ben
Flags: blocking0.8? → blocking0.8-

    
    

    
  
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.

    
    

    
  
This bug has always been Windows only.

    
    

    
  
(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.

    
    

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

    
    

    
  
(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.

    
    

    
  
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+

    
    

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

    
    

    
  
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
Flags: blocking0.9?

    
    

    
  


  
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 #87 this is not the right bug.  File a new one if you can't find the
right one.

    
    

    
  
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.
Flags: blocking0.9? → blocking0.9-

    
  
Flags: blocking1.0?

    
  
Flags: blocking1.0? → blocking1.0+

    
    

    
  
possibly related to bug 240095?

    
    

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

    
    

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

    
  
Keywords: conversion

    
    

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

Seconded!

    
    

    
  
(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.

    
    

    
  
(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.

    
    

    
  
(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.

    
    

    
  
(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.


    
    

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

    
    

    
  
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.
Flags: blocking0.8-
Keywords: conversion, 
          
            fixed1.4.1, 
          
            nsbeta1-, 
          
            pp

    
    

    
  


  
Assignee: bugs → aaronleventhal

    
  

        Attachment #156358 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #156358 -
        Flags: review?(mconnor)

    
    

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

looks good to me

        Attachment #156358 -
        Flags: review?(mconnor) → review+

    
    

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

No sr= needed

        Attachment #156358 -
        Flags: superreview?(neil.parkwaycc.co.uk) → approval-aviary?

    
    

    
  
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.

        Attachment #156358 -
        Flags: approval-aviary? → approval-aviary+

    
    

    
  
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

Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED

    
    

    
  
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.  

    
    

    
  
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. 

    
    

    
  
verified based on above comment
Status: RESOLVED → VERIFIED

    
    

    
  
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?

    
    

    
  
(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

    
    

    
  
> 
> 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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: