Closed Bug 395314 Opened 17 years ago Closed 17 years ago

Larry UI: click to close

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
All
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3 beta1

People

(Reporter: mikeclackler, Assigned: johnath)

References

Details

Attachments

(1 file, 1 obsolete file)

Consume the rollup event
(deleted), patch
Gavin
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007090604 Minefield/3.0a8pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007090604 Minefield/3.0a8pre

There is no apparent way to close the description pop up in the UI.  Clicking the Larry UI in the URL box should open the info pop up if it is closed, and also close the pop up if it is open.  Click-to-open, click-to-close.

Reproducible: Always

Steps to Reproduce:
1.Go to bugzilla
2.Click Larry UI "bugzilla.mozilla.org" in URL box
3.Pop up with info is presented
4.With pop up open, click Larry UI "bugzilla.mozilla.org" in URL box again
Actual Results:  
info pop up re-opens

Expected Results:  
info pop up closes and remains closed
Depends on: larry
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3?
to clarify, if larry is open, I'd like to be able to click on the "bugzilla.mozilla.org" box or the larry popup to make it go away.

right now, only clicking on the "Tell me more about this web site..." link closes larry.
(In reply to comment #2)
> right now, only clicking on the "Tell me more about this web site..." link
> closes larry.

It doesn't close larry for me with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007090704 Minefield/3.0a8pre -- the window appears behind larry.
I agree, this sucks.  Patch changes onmouseup code into onclick code which is the proper way to behave here - one click opens, next click dismisses.  This patch also wraps the openPopup in a setTimeout call, since otherwise the first open in a session happens before the unhiding takes effect.
Assignee: nobody → johnath
Status: NEW → ASSIGNED
Attachment #280105 - Flags: review?(gavin.sharp)
Attachment #280105 - Flags: review?(gavin.sharp) → review+
Attachment #280105 - Flags: approval1.9?
Comment on attachment 280105 [details] [diff] [review]
Switch to onclick instead of onmouseup, and add setTimeout to handle hiding properly

a=me for landing tonight or very early tomorrow (Saturday)
Attachment #280105 - Flags: approval1.9? → approval1.9+
>There is no apparent way to close the description pop up in the UI.

Perhaps we should add a small close button to the upper left of the window, and make sure this is consistent between Larry and the star popup for places.
Flags: in-litmus?
OS: Windows Vista → All
Hardware: PC → All
Version: unspecified → Trunk
As soon one adds a 'close' button, the panel should be a popup/dialogbox, and then why not combine the panel with the Page Info/Security panel instead of having two different forms for the same info?
> since otherwise the first open in a session happens before the unhiding takes
> effect.

That's really odd.  That shouldn't be happening, what with the popup open being async and presumably flushing style changes as needed.  Is there a bug filed on the popup code for this issue?

I filed bug 396983 to make the setTimeout part of this patch unnecessary.
Depends on: 396983
The most recent checkin of bug 383183 changes the box to respond to onclick, instead of onmouseup.  This has the effect of fixing this bug on Mac, but the behaviour persists on windows.
Flags: blocking-firefox3? → blocking-firefox3+
Litmus triage team: to be added in Litmus by Tomcat or juanb
Target Milestone: --- → Firefox 3 M9
Whiteboard: [has patch] waiting on Larry relanding
Since bug 383183 has landed again, can this be landed to fix one of Larry's more annoying "features"?
Actually, most of this patch was included in the larry re-landing except for the part from bug 395062, which isn't needed anymore since bug 394887 was fixed.
fixed with landing for bug 383183
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [has patch] waiting on Larry relanding
I'm not sure this is fixed on windows, and my build machine is taking a while to wake up.  As mentioned, the existing patch was rolled into bug 383183 during a relanding, but IIRC, there are still issues on windows.  Can the originator or someone else comment as to whether this behaviour is fixed?  Otherwise I'll get a build running on Vista later today to check.
This isn't fixed for me on Windows Vista.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007102205 Minefield/3.0a9pre ID:2007102205
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a9pre) Gecko/2007102204 Minefield/3.0a9pre

comment #2: fixed
comment #3: not fixed
Status: RESOLVED → REOPENED
OS: All → Windows Vista
Resolution: FIXED → ---
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102122 Minefield/3.0a9pre ID:2007102122

comment #2: fixed
comment #3: not fixed

Comment on attachment 280105 [details] [diff] [review]
Switch to onclick instead of onmouseup, and add setTimeout to handle hiding properly

Resetting all approval1.9+ flags on bugs that have not been checked in by Oct 22 11:59 PM PDT.  Please re-request approval if needed.
Attachment #280105 - Flags: approval1.9+
Comment on attachment 280105 [details] [diff] [review]
Switch to onclick instead of onmouseup, and add setTimeout to handle hiding properly

Most of this patch landed as part of the Larry relanding yesterday.
with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102304 Minefield/3.0a9pre, neither clicking on the larry popup or on the original "domain" box that opened the larry popup will close the larry popup.

Note, I'm running on Windows XP (so this is not vista only)


Also, what about a keybinding to "esc" (escape) for the popup Larry UI?  Maybe I should file a new bug.
Comment on attachment 280105 [details] [diff] [review]
Switch to onclick instead of onmouseup, and add setTimeout to handle hiding properly

Part of this patch was rolled into 383183 and fixed the problem on mac.  Will attach a new patch here that fixes the remaining windows issue.
Attachment #280105 - Attachment is obsolete: true
Attached patch Consume the rollup event (deleted) — — Splinter Review 
This patch tells the popup to consume the rollup (disappear) event rather than delivering the mouse click to the identity box (which in turn caused it to reappear).  

Confirmed on XP and Vista as fixing the original problem ("Clicking
the Larry UI in the URL box should open the info pop up if it is closed, and
also close the pop up if it is open.")

Seth points out that he would also like to see clicks within the popup dismiss the popup.  I'm not sure I agree - you'd have to be careful near the "tell me more" link, since a mis-click could (frustratingly) dismiss the dialog instead of opening the security info box, and this is not how other popups, menus, and the like behave.

In any event, I think this was blocking because of the original complaint, and the disparity between windows and mac behaviour, so my suggestion would be to review this patch as a solution to the problem and file a follow-up bug on the other issue, if Seth would like to pursue it.
Attachment #285903 - Flags: review?(gavin.sharp)
Comment on attachment 285903 [details] [diff] [review]
Consume the rollup event

r=me
Attachment #285903 - Flags: review?(gavin.sharp) → review+
Checking in browser/base/content/browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.876; previous revision: 1.875
done
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
thanks for fixing this.  

> Seth points out that he would also like to see clicks within the popup dismiss
> the popup.

even with this fix, I claim it's not obvious how to close the larry popup once it is open.

I see we have one bug (#395174: Identity pop-up should disappear as soon as I start typing in the location bar) about closing.  

Do we have any about adding some sort of close box?  (I didn't see any.)

> this is not how other popups, menus, and the like behave.

I think we've got some similar "close" issues with the bookmark pop-up that you get when you click on the "star" button.

perhaps faaborg can also comment on what would be best?
> Do we have any about adding some sort of close box?  (I didn't see any.)

logged bug #400883, my apologies if this is a dup.

> Also, what about a keybinding to "esc" (escape) for the popup Larry UI?  Maybe
> I should file a new bug.

stephen, did you log that bug?
(In reply to comment #29)
> > Also, what about a keybinding to "esc" (escape) for the popup Larry UI?  Maybe
> > I should file a new bug.
> 
> stephen, did you log that bug?

Sorry for the delay; just did, here: 400893.

>even with this fix, I claim it's not obvious how to close the larry popup once
>it is open.
>
>I see we have one bug (#395174: Identity pop-up should disappear as soon as I
>start typing in the location bar) about closing.  
>
>Do we have any about adding some sort of close box?  (I didn't see any.)
>
>perhaps faaborg can also comment on what would be best?

Madhava and I were actually just talking about this today.  Larry is one of at least 6 instances of this type of UI (which we call a contextual dialog).  Another example of a contextual dialog is the bookmark UI you get when clicking on the star.

These were designed so that clicking anywhere outside of the contextual dialog dismisses it, which is an incredibly large and super easy to hit target area.

However, this interaction also isn't discoverable, you literally have to guess that you can do it, try it, and see that it works.  This will feel like a bad UI the first time you encounter a contextual dialog, because you may be confused.  Some users might even get up and find a friend to ask "how do I make this thing go away."

So why not just add a close button?  We certainly could, but the reason that both Madhava and I are wary of doing so is this: if the user learns to close the window by clicking on the 12x12 X icon the first time, they may proceed to do this every time they interact with the user interface.  On my monitor, the target area for closing a contextual dialog is 1900x1200, which is 15,833 times larger than a 12x12 target area.  So we are looking at trading discoverability on the first interaction, for the possibility of the user wasting a few seconds of target acquisition and mouse movement on every single subsequent interaction.

We haven't totally decided yet, but those are the issues we are currently considering.
In reply to comment #31 :
A 12x12 button sounds like an [X] button at the end of the dialog's titlebar. A "Close" or "OK" button below the text would be larger than that, maybe 25x75 pixels or some such. But these dialog-closing methods need not be exclusive: why not have a dialog that could be closed by an [X] at top right, or a [Close] or [OK] at bottom center, or by clicking anywhere outside the dialog, whichever happens first?
No longer depends on: larry
Blocks: larry
>But these dialog-closing methods need not be exclusive:
>why not have a dialog that could be closed by an [X] at top right, or a [Close]
>or [OK] at bottom center

For some notifications we will have choice buttons that will dismiss the dialog, for instance the "would you like firefox to remember your password" notification will have the usual [Yes], [No], [Never].  However, contextual dialogs are also used for menu and instant apply interfaces where we can't place [Ok] buttons.  The close button would still work in these instances, but I'm worried that training users to complete a task with a slow interaction has an overall negative effect, as opposed to initially a small amount of confusion, followed by streamlined interactions.
Verified.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007102404 Minefield/3.0a9pre

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102504 Minefield/3.0a9pre
Status: RESOLVED → VERIFIED
created the litmus test for this -> in-litmus +
Flags: in-litmus? → in-litmus+
I don't really see how the status is from reading the comments. If you open the Identity popup and press the link, what is supposed to happen?

For me (on linux) the Info dialog still opens BEHIND the Identity popup. Please either close the popup when the link is pressed, or at least display the Info dialog in front of it (I would prefer the first, though).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: