Closed
Bug 620145
Opened 14 years ago
Closed 14 years ago
Prompt for gmail message with no text has to be focused (clicked on) before ok-ing (or canceling)
Categories
(Toolkit :: General, defect)
Tracking
()
RESOLVED
FIXED
mozilla2.0b9
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: Peter6, Assigned: enndeakin)
References
Details
(Keywords: regression)
Attachments
(2 files, 1 obsolete file)
61 bytes,
text/html
|
Details | |
4.23 KB,
patch
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20101218 Firefox/4.0b9pre ID:20101218030347 repro: open gmail make a new message with title but without text hit [send] a modal message pops up asking me if i want send the message w.o text click [ok] result: nothing happens you havce to click [ok] twice to send the message this regressed when the dialog changed from global to modal
Comment 1•14 years ago
|
||
Confirm this bug for Windows 7 x86. Mozilla/5.0 (Windows NT 6.1; rv:2.0b9pre) Gecko/20101218 Firefox/4.0b9pre ID:20101218030347
![]() |
||
Updated•14 years ago
|
Updated•14 years ago
|
Keywords: regressionwindow-wanted
![]() |
||
Comment 3•14 years ago
|
||
And it need click twice for switching tab/activate menu/execution toolbar button,. No tooltip or wrong tooltip pops up for toolbar button.
Comment 4•14 years ago
|
||
Confirmed using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101227 Firefox/4.0b9pre ID:20101227030354 Regression range... Last good nightly: 2010-11-19 First bad nightly: 2010-11-20 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6478c1b83d60&tochange=baa6cc2f72e4 In this range is: Bug 59314 - Alerts should be content-modal, not window-modal ...so modal alerts likely cause, as expected. In addition, when the new style alert appears after following the STR, the question mark image does not appear straight away and the tooltip for the OK button is empty and appears as just a grey box. Is this related or should it be logged separately?
Keywords: regressionwindow-wanted
Reporter | ||
Comment 5•14 years ago
|
||
(In reply to comment #4) > In addition, when the new style alert appears after following the STR, the > question mark image does not appear straight away and the tooltip for the OK > button is empty and appears as just a grey box. Is this related or should it be > logged separately? not the same, file a new bug. I can confirm, the delay only happens once (the first time).
Comment 6•14 years ago
|
||
If you leave the prompt open without dismissing it a stop script dialog comes up for the following line: file:///C:/Users/Natch/Documents/mozilla_trunk/m-c_release/dist/bin/components/nsPrompter.js:463 Where the prompter is looping over args.promptActive and spinning the event loop (I think). There's something wrong there apparently...
Comment 8•14 years ago
|
||
Filed bug 621764, although I think that is the cause for this bug. I've set the dependency as such.
Comment 9•14 years ago
|
||
I realize the bug report is a little misleading, so updated the subject accordingly. What's actually happening is that the first click doesn't get caught by the prompt, it just "focuses" it.
Summary: gmail message with no text has to be ok-ed twice to send → Prompt for gmail message with no text has to be focused (clicked on) before ok-ing (or canceling)
Comment 10•14 years ago
|
||
A simple and obvious way to repro is: 1) Open two windows 2) In one window, enter data:text/html,<script>confirm("confrim");</script> 3) When the confirm comes up, close the second window with the windows X button ER: Second window closes and prompt can be dismissed in first window on first click. AR: Second window doesn't close and prompt needs two clicks to close (after which the second window can be closed).
Updated•14 years ago
|
Product: Core → Toolkit
QA Contact: general → general
Target Milestone: mozilla2.0 → ---
Comment 11•14 years ago
|
||
(In reply to comment #5) > (In reply to comment #4) > > In addition, when the new style alert appears after following the STR, the > > question mark image does not appear straight away and the tooltip for the OK > > button is empty and appears as just a grey box. Is this related or should it be > > logged separately? > > not the same, file a new bug. > I can confirm, the delay only happens once (the first time). Filed as bug 621672 and bug 622340.
Comment 12•14 years ago
|
||
Seems focus is shifting back to to the gmail page; but it's weird... Following the STR in comment 0, once the prompt is up: * Tabbing works as expected, moving around chrome and (apparently) not in content. "Ok" button is focused initially, and pressing tab once moves it to cancel. * After clicking one of the tab-modal prompt buttons (which should trigger the button's command, but apparently doesn't), focus is shifting into content. Pressing Tab now shifts focus around in the Gmail page! O_o Not sure why focus manager is allowing tab to move around in a page that shouldn't be focusable (maybe it's not expecting focus to be able to get there in the first place?). CCing Enn, note that I was testing with bug 617872's patch applied. I flipped on the focus manager debugging, starts with me typing in the Subject field: **Element (none) has been blurred **Element input has been focused from html [Newdoc: 1 FocusChanged: 1 Raised: 0 Flags: 1002] Update Caret: 0 1 <<SetFocus>> Shift Focus: div Flags: 0 Current Window: 0F3FE6D8 New Window: 0F3FE6D8 Current Element: 125797F8 In Active Window: 1 In Focused Window: 1 **Element input has been blurred Update Caret: 0 1 **Element div has been focused from html [Newdoc: 0 FocusChanged: 1 Raised: 0 Flags: 0] Update Caret: 1 0 <<SetFocus>> Shift Focus: button Flags: 0 Current Window: 0F3FE6D8 New Window: 0496A108 Current Element: 0A236188 In Active Window: 1 In Focused Window: 0 **Element div has been blurred **Element button has been focused from window [Newdoc: 1 FocusChanged: 1 Raised: 0 Flags: 0] Update Caret: 1 1 *click button* <<ClearFocus begin>> <<ClearFocus end>> <<SetFocusedWindow begin>> Shift Focus: (none) Flags: 0 Current Window: 0496A108 New Window: 0F3FE6D8 Current Element: 0F0A62C8 In Active Window: 1 In Focused Window: 0 **Element button has been blurred **Element (none) has been focused from html [Newdoc: 1 FocusChanged: 0 Raised: 0 Flags: 0] Update Caret: 0 1 <<SetFocusedWindow end>> Tomorrow I'll try breakpointing to see what's causing the "Element (none) has been focused from html".
Assignee | ||
Comment 14•14 years ago
|
||
The first mouse event seems to be fired at the page rather than at the chrome window. The second mouse event is fired at the chrome window.
Assignee | ||
Comment 15•14 years ago
|
||
This issue relates to the active EventStateManager tracking added by bug 582771 and 603550. Backing out bug 603550, for instance, fixes this bug. Also, activating the Send button with the keyboard works. Pressing the button calls nsEventStateManager::SetActiveManager on the page, but for some reason the call to nsEventStateManager::ClearGlobalActiveContent isn't happening, so the PresShell believes the page is still active even though the alert is displayed.
Assignee | ||
Comment 16•14 years ago
|
||
Actually, just showing an alert during a mouseup event causes this bug. Perhaps ClearGlobalActiveContent just needs to be called from nsGlobalWindow::EnterModalState?
Comment 17•14 years ago
|
||
Yeah, something like that could work. ClearGlobalActiveContent should be probably called only if globalwindow or any of its ancestor or descendant window is focused.
Updated•14 years ago
|
Attachment #501388 -
Attachment is patch: false
Updated•14 years ago
|
Attachment #501388 -
Attachment mime type: text/plain → text/html
Assignee | ||
Comment 18•14 years ago
|
||
(In reply to comment #17) > Yeah, something like that could work. > ClearGlobalActiveContent should be probably called only if > globalwindow or any of its ancestor or descendant window is focused. Why is the focus relevant?
Assignee | ||
Comment 20•14 years ago
|
||
Comment 21•14 years ago
|
||
Reconfirm this bug for: Mozilla/5.0 (Windows NT 6.1; rv:2.0b9pre) Gecko/20110106 Firefox/4.0b9pre ID:20110106030349
Comment 22•14 years ago
|
||
Comment on attachment 501688 [details] [diff] [review] patch >+ // If there is an active ESM in this window, clear it. Otherwise, this can >+ // cause a problem if a modal state is entered during a mouseup event. >+ nsEventStateManager* activeESM = >+ static_cast<nsEventStateManager*>(nsEventStateManager::GetActiveEventStateManager()); >+ if (activeESM && activeESM->GetPresContext()) { >+ nsIPresShell* activeShell = activeESM->GetPresContext()->GetPresShell() >+ nsCOMPtr<nsIDocument> doc = do_QueryInterface(mDocument); You could just use mDoc. >+ if (activeShell && ( >+ nsContentUtils::ContentIsCrossDocDescendantOf(activeShell->GetDocument(), doc) || >+ nsContentUtils::ContentIsCrossDocDescendantOf(doc, activeShell->GetDocument()))) { >+ nsEventStateManager::ClearGlobalActiveContent(nsnull); I think you should pass activeESM as parameter, so that whatever is ACTIVE in that document, gets cleared. Could you still try what happens if web page calls window.print(). Things should be just ok in that case, but better to test.
Attachment #501688 -
Flags: review?(Olli.Pettay) → review+
Assignee | ||
Comment 23•14 years ago
|
||
Comment 24•14 years ago
|
||
Pushed http://hg.mozilla.org/mozilla-central/rev/5e8b96f85355 Thanks for grabbing this and fixing so fast!
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b9
Updated•14 years ago
|
Attachment #501688 -
Attachment is obsolete: true
Comment 25•14 years ago
|
||
Oops, test was broken. Disabled in http://hg.mozilla.org/mozilla-central/rev/534adf40eb8b Fixed and reenabled in http://hg.mozilla.org/mozilla-central/rev/7b08fef26335 Just needed to include EventUtils.js, but I left some of the extra debugging in lest the test ever cause problems again.
You need to log in
before you can comment on or make changes to this bug.
Description
•