Stefan Reporter
	Description • 14 years ago

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110115 Firefox/4.0b10pre

follow-up to Bug 622326

Reproducible: Always

Steps to Reproduce:
1. open testcase in tab 1 
2. open testcase in tab 2
3. press OK button in tab 1
Actual Results:  
1. spinner of tab 1 keeps running
2. "Original content"

Expected Results:  
1. spinner of tab 1 stops
2. "Original content" and "Extra content"

	Stefan Reporter
	Comment 2 • 14 years ago

STR continuated:

4. press OK buttin in tab 2

Actual: Result:
Both spinner stop and both tabs show expected text.

	:Paolo Amadini
	Comment 3 • 14 years ago

Thanks for the reporting the problem. Unfortunately, the behavior you observed,
although undesired, is unavoidable with the current architecture. I think that
many other major web browsers would behave in the same or similar ways if you
follow the same steps using two windows instead of two tabs.

There is a project code-named Electrolysis (e10s) that basically will render
the execution of web pages or group of pages independent from each other.
That will help mitigate or solve this problem. Electrolysis, however, is a
complex project made of various parts, and the required part will take time
to be completed.

	Stefan Reporter
	Comment 4 • 14 years ago

Well. Google Chrome blocks all tabs and all windows upon confirm. KDE Konqueror and opera only block the current window and all tabs therein,

	Justin Dolske [:Dolske]
	Comment 5 • 14 years ago

This is known and expected.

Opening the 2nd modal prompt spins a second event loop. So while clicking ok in the 1st tab makes the dialog go away, control can't return to the script in that page until the 2nd event loop is completed (by dismissing the prompt in the second tab).