Weave Sign-In Dialog won't go away until I close all "Help" windows that it spawned

RESOLVED FIXED in 0.6

Status

Cloud Services
Firefox Sync: UI
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: dholbert, Assigned: anant)

Tracking

({polish})

unspecified
polish
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [good first bug])

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Steps to reproduce:
 1. Sign out of Weave (if you're signed in).
 2. Click Weave icon in status bar, and choose "Sign In".
 3. Click "Help" on the sign-in dialog.
    --> This brings up a new browser window pointed to a help URL (which is currently "Not Found" -- bug 445068).
    ** Don't close this new "Help" browser window. **
 4. Click "Sign In" on the sign-in dialog.

ACTUAL RESULTS:
  Sign in dialog remains open, after you're signed in, **until you close the new "Help" browser window.**
  -- Clicking 'Cancel' does nothing.
  -- Clicking 'Help' again brings up *another* browser window, which must also be closed before the dialog will dismiss itself.
  -- Pressing 'Esc' does nothing.

  The only way I can find to close the dialog (aside from closing its "Help" browser window(s)) is to click the "x" close button on the window's title bar.

This bug is particularly nasty because:
  - The Weave sign-in dialog is modal -- i.e. it blocks all interaction with the window behind it.  So, it really sucks when it won't go away.
  - The spawned "Help" window looks just like any other browser window, which makes it hard for the user to tell that the sign-in dialog's behavior depends on this window.  This is particularly true when there's no actual weave help content present in the window, as is the current situation. :) (bug 445068)

VERSION INFO:
Ubuntu Linux 8.04
Firefox 3.0.0
Weave 0.2.4
(Reporter)

Comment 1

10 years ago
Created attachment 329364 [details]
screenshot of issue

Comment 2

10 years ago
Same on windows, OS -> ALL
OS: Linux → All
(Reporter)

Comment 3

9 years ago
I still see this bug in Weave 0.2.98.  Version --> Trunk
Version: unspecified → Trunk

Updated

9 years ago
Hardware: x86 → All
Target Milestone: -- → Future

Updated

9 years ago
Component: Weave → General
Product: Mozilla Labs → Weave
Version: Trunk → unspecified
QA Contact: weave → general
Opening a window from a modal dialog/window will cause that window to be modal.

bug 425419 is a similar bug in Firefox.
Severity: major → normal
Component: General → Firefox UI
Keywords: polish
QA Contact: general → firefox
Whiteboard: [good first bug]
Target Milestone: Future → 1.0

Updated

9 years ago
Target Milestone: 1.0 → 0.6
(Assignee)

Comment 5

9 years ago
http://hg.mozilla.org/labs/weave/rev/4e8afad961ae
Assignee: nobody → anant
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
is _openWin going to be a public method on Utils then?

Comment 7

9 years ago
There is a Utils.openWindow method that wraps Utils._openWin. Not sure why that wasn't used.

Comment 8

9 years ago
Ah. You want to open a http uri instead of chrome uri. I suppose openWindow could detect if it should prepend chrome content or just use the full uri.
or add an openContentWindow method for non-chrome windows.  Either way, we shouldn't call private methods from other components.

This is the type of thing that code review would catch, please don't bypass the process...
(Assignee)

Comment 10

9 years ago
Created attachment 391029 [details] [diff] [review]
Re-structure window utils

Re-structure window utils to remove usage of private methods.
Attachment #391029 - Flags: review?
(Assignee)

Updated

9 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

9 years ago
Attachment #391029 - Flags: review? → review?(mconnor)
Comment on attachment 391029 [details] [diff] [review]
Re-structure window utils

If you're using it to open chrome windows, _openChromeWindow would be correct naming.
Attachment #391029 - Flags: review?(mconnor) → review+
(Assignee)

Comment 12

9 years ago
http://hg.mozilla.org/labs/weave/rev/5e639c1f6ebe
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.