Closed Bug 402415 Opened 17 years ago Closed 16 years ago

Clicking Larry's "Tell me more about this website" link opens the Page Info dialog but doesn't close Larry

Categories

(Firefox :: General, defect, P4)

Product:
Firefox
Component:
General
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Firefox 3 beta3

People

(Reporter: reed, Assigned: johnath)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

Simple approach
986 bytes, patch
Gavin
: review+
Details | Diff | Splinter Review 
When I click the "Tell me more about this website" link on Larry's UI, the Page Info dialog opens but Larry doesn't close (and is, therefore, in front of the Page Info dialog). :(

So, Larry should either close once that link has been clicked or it should go to the background behind the Page Info dialog so that it doesn't cover up the Page Info dialog.
Flags: blocking-firefox3?
One would think somebody has filed a bug on this, but I can't find one. :(
Whiteboard: DUPEME?
Using  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9a9pre) Gecko/2007110404 Minefield/3.0a9pre, I don't see this on Mac, which is a good thing.
Can't reproduce with bug Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110405 Minefield/3.0a9pre.
Must be a Linux-only thing then, as I can reproduce it every time. :(

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007110404 Minefield/3.0a9pre
I also can reproduce this one on Linux with:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a9pre) Gecko/2007110404 Minefield/3.0a9pre

Clicking the popup explicitly would probably be easy. But I don't know why this is bug happening in the first place.

Neil?
(In reply to comment #6)
> Clicking the popup explicitly

err, closing it.
Also, Alt+Tab isn't working on Linux if a panel is open.
Attached patch Simple approach — — Splinter Review 
Assuming this is not something subtle and complicated, this should fix it?  On the other platforms, it isn't necessary to explicitly dismiss the popup, but it's probably not a terrible thing to do anyhow, since it's the intended behaviour.
(In reply to comment #8)
> Also, Alt+Tab isn't working on Linux if a panel is open.

Gavin pointed me out and I've noticed that the Alt+Tab bug is general to popups.

You can't use alt+tab on Linux while a popup is open. The forms autocomplete popups disappear after pressing alt+tab once, but the URL bar autocomplete popup won't...
might be due to bug 401712.
Flags: blocking-firefox3? → blocking-firefox3+
Reed - does this fix your problem?  (Taking the bug, in any case.)
Assignee: nobody → johnath
Please don't miss to ask Neil Deakin why this is happening in the first place. It looks like a Core bug to me.
I think you're right Dao - he gets back Monday - even if this fixes Reed's problem, I won't land/resolve until we get his input, and potentially send it over to him for a backend fix.
Target Milestone: --- → Firefox 3 M11
This is bug 385274. gtk should be rolling up popups when another window is activated, as Mac and Windows do.
Depends on: 385274
(In reply to comment #14)
> This is bug 385274. gtk should be rolling up popups when another window is
> activated, as Mac and Windows do.

So why is bug 385274 filed as a Mac bug?
OK, yeah, that bug isn't what I thought it was.
Whiteboard: DUPEME?
Priority: -- → P4
Anything new here? It still happens on linux, would be nice to have this fixed for beta 2...
(In reply to comment #16)
> OK, yeah, that bug isn't what I thought it was.

(In reply to comment #17)
> Anything new here? It still happens on linux, would be nice to have this fixed
> for beta 2...

Neil - any follow-ups?  Seeing different rollup behaviour on link click in linux vs. other platforms feels like a platform-level thing, and I don't really want to land the workaround fix that just manually hides the panel on link click if the correct approach is to fix this in Core.
The bug still appears in firefox3b2. If it can't be fixed before a final release, probably it's better to add Johnathan's workaround, than to not to fix it at all.
Comment on attachment 287401 [details] [diff] [review]
Simple approach

This is a P4, so it might not make anyone's priority list, but I'll put it in Gavin's review queue anyhow.

Neil agrees that there is a platform bug here, but that it's unlikely to be fixed before ship, so if this gets reviewed and landed, I'll open a follow-up on platform to fix the underlying issue, and mention that this code should be removed as part of that.
Attachment #287401 - Flags: review?(gavin.sharp)
(In reply to comment #20)
> (From update of attachment 287401 [details] [diff] [review])
> This is a P4, so it might not make anyone's priority list, but I'll put it in
> Gavin's review queue anyhow.

If you expect to use Larry at all for Firefox 3, this should be a lot higher than a P4, as it makes Larry extremely annoying on Linux.
Comment on attachment 287401 [details] [diff] [review]
Simple approach

Thanks goodness this critical issue was caught in time.
Attachment #287401 - Flags: review?(gavin.sharp) → review+
Not going to continue to block on this, please renominate with reasons why we can't ship with this in final
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
I have to second Reed, the larry ui is very annoying this way, I really hope this will get fixed before release...
So, this bug already has a patch waiting to land, and as I said in previous comments, if Larry is to be at all used in Firefox 3, this is a real distraction on Linux.
Flags: blocking-firefox3- → blocking-firefox3?
Reed, please only renominate if you have something concrete other than "this is annoying."  Otherwise you're just spamming and wasting drivers' time.
Flags: blocking-firefox3? → blocking-firefox3-
Comment on attachment 287401 [details] [diff] [review]
Simple approach

This is apparently a significant pain on linux, and the patch is a two-liner that only impacts Larry code.  Not critical, but also not risky.
Attachment #287401 - Flags: approval1.9?
Blocks: 408211
(In reply to comment #27)
> (From update of attachment 287401 [details] [diff] [review])
> This is apparently a significant pain on linux, and the patch is a two-liner
> that only impacts Larry code.  Not critical, but also not risky.

I thought you rolled this fix into one of your other changes, as I haven't seen this bug in a long time...
(In reply to comment #28)
> (In reply to comment #27)
> > (From update of attachment 287401 [details] [diff] [review] [details])
> > This is apparently a significant pain on linux, and the patch is a two-liner
> > that only impacts Larry code.  Not critical, but also not risky.
> 
> I thought you rolled this fix into one of your other changes, as I haven't seen
> this bug in a long time...

I didn't, and mxr/cvs agrees that the code doesn't exist in the tree:

http://mxr.mozilla.org/mozilla/source/browser/base/content/browser.js#5868

On the other hand, this bug was never "supposed" to happen, and I don't have a linux box around, so if you want to resolve this WFM, that WFM.
Comment on attachment 287401 [details] [diff] [review]
Simple approach

taking this off the approval queue until I know whether it actually needs to land or not.
Attachment #287401 - Flags: approval1.9?
Not sure when this got fixed, but I haven't seen it in a while. --> WFM
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
I'm seeing this issue again in a current trunk build on Linux. Should I file a new bug for it or reopen this one?
Please file a new bug with a regression range.
(In reply to comment #32)
> I'm seeing this issue again in a current trunk build on Linux. Should I file a
> new bug for it or reopen this one?

I can confirm this. Please file a new bug, though. CC me when you file it, please? :)
(In reply to comment #34)
> Please file a new bug, though. CC me when you file it, please? :)

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

Attachment

General

Creator:
Created:
Updated:
Size: