Michal Čaplygin [:myf] Reporter
	Description • 14 years ago

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.

Notes
-------
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.

	Tim (fmdeveloper)
	Comment 1 • 14 years ago

Reporter -> Are you still experiencing this issue with the latest builds?

	Michal Čaplygin [:myf] Reporter
	Comment 2 • 14 years ago

Minefield 4.0b9pre (2010-12-30), followed instructions from description …

	Ed Morley [:emorley]
	Comment 3 • 14 years ago

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
...so 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

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7f5cd850578e&tochange=32cd5d95a95f

	Michal Čaplygin [:myf] Reporter
	Comment 4 • 14 years ago

HTML page with body.onmouseup function generating prompt. As in 2011-01-01 shows the bug well.

	Michal Čaplygin [:myf] Reporter
	Comment 5 • 14 years ago

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.

	Nochum Sossonko [:Natch]
	Comment 6 • 14 years ago

This is essentially bug 620145 but I don't think that fixed it completely. Cc'ing Enn.

	Neil Deakin Assignee
	Comment 7 • 14 years ago

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.

	Neil Deakin Assignee
	Comment 9 • 14 years ago

http://hg.mozilla.org/mozilla-central/rev/e81b9a8b6cce

	Michal Čaplygin [:myf] Reporter
	Comment 10 • 14 years ago

// Thanks for fixing it, works well now :]