Closed Bug 615186 Opened 13 years ago Closed 13 years ago

[QAC generated] New alert() pseudomodal pseudodialog does not recieve focus while pages mouseup event is being handled.


(Toolkit :: General, defect)

Windows XP
Not set



Tracking Status
blocking2.0 --- betaN+


(Reporter: myf, Assigned: enndeakin)



(Keywords: regression, Whiteboard: [softblocker][fx4-fixed-bugday])


(3 files, 1 obsolete file)

Steps to Reproduce
1. Write into URL bar:
   javascript:document.body.onmouseup=function(){alert(++window.cnt)};window.cnt=0;void 0;
   on any web page and press enter.
2. Click anywhere on the page.
3. (Just for effect, wait for the blured images render [even in Nigtly from 2010-11-29 it takes considerable amount of time and CPU], move your mouse and watch text selection growing and shinging under the 'blured glass')
4. Try to click "OK" with yout mouse.
5. Suffer.

What should have happened:
- Page released fucus (just like in good old builds) so no text selectin under the "glass" is possible.
- Dialog recieved focus.
- Click closed alert pseudowindow and returned focus to the page.

What actually happened:
- New pseudmodal pseudowindow appeared with increased counter. As long as you will continue clicking OK with mouse, new alerts are spawned above old ones.

I suppose that as at 2010-11-29 the Minefields implementation of new modal dialogs is just kinda proof-of-concept, but it is not only terrible-looking, but it also works bad.
Reporter -> Are you still experiencing this issue with the latest builds?
Minefield 4.0b9pre (2010-12-30), followed instructions from description …
Depends on: 59314
Product: Firefox → Toolkit
QA Contact: general → general
Confirmed using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101231 Firefox/4.0b9pre ID:20101231030358

Interestingly, the main regression for this issue was a few days after the initial tab modal patch.

1st Regression: (More minor, testcase above needs two clicks to close dialog, but at least you can close them)
Last good nightly: 2010-11-19 
First bad nightly: 2010-11-20 therefore due to the landing of bug 59314.

2nd Regression: (Results in not being able to dismiss the dialog boxes by pressing ok, since they stack up on top of each other)

Last good nightly: 2010-11-24
First bad nightly: 2010-11-25

blocking2.0: --- → ?
Ever confirmed: true
Keywords: regression
HTML page with body.onmouseup function generating prompt. As in 2011-01-01 shows the bug well.
Blocks: 59314
No longer depends on: 59314
I have noticed (as in v.2011-01-02, probably haven't tried before) after first dialog had been shown, even clicking at any main window's chrome element (main menu, extensions bar, awesomebar, navigation buttons, tab bar etc) is handled and generates new dialog. So there is no way to close the test page's tab or switch to another using mouse; only keyboard actions like ctr+w or ctr+tab works.
And funny remark about right clicking while test dialog is being shown: context menu is displayed after closing the test page on page that received focus.
Assignee: nobody → dolske
blocking2.0: ? → betaN+
Whiteboard: [soft blocker]
This is essentially bug 620145 but I don't think that fixed it completely. Cc'ing Enn.
Whiteboard: [soft blocker] → [softblocker]
Attached patch patch to fix selection (obsolete) — Splinter Review
This is actually two bugs. The first is that selecting isn't disabled when an alert appears. The second is that multiple dialogs appear and is probably bug 618856 or bug 622663.

This patch fixes the first and I will work on a test for it.
Assignee: dolske → enndeakin
Attached patch patch with testSplinter Review
Attachment #503186 - Attachment is obsolete: true
Attachment #503256 - Flags: review?(Olli.Pettay)
Attachment #503256 - Flags: review?(Olli.Pettay) → review+
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
// Thanks for fixing it, works well now :]
Whiteboard: [softblocker] → [softblocker][fx4-fixed-bugday]
You need to log in before you can comment on or make changes to this bug.