388280 - "Show (blocked popup-URL)" does not work.

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[pal-moz]

regress between 20070704_0524 and 20070704_0857

[range]
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1183551840&maxdate=1183564619

Comment 1

[Neil Deakin]

Seems like nsDOMEvent::GetEventPopupControlState returns openAbused from within a popupshowing event now, instead of openControlled. As popupshowing is now fired asynchronously, this is likely because the popupshowing event isn't happening during user input any more. Thus, the new blocked popup isn't opening.

Not sure of the best way to fix this, but is there some reason why a chrome caller  doesn't override the popup blocking check?

Comment 2

[Neil Deakin]

Attachment: use a flag to indiciate if in user input mode

Comment 3

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 273235 [details] [diff] [review]
use a flag to indiciate if in user input mode

Seems reasonable.  I assume this gives somehow better behavior than just pushing whatever the popup blocking state in ExecuteMenu() was?

Comment 4

[Boris Zbarsky [:bzbarsky]]

That is, pushing that and not changing nsDOMEvent at all.

Comment 5

[Neil Deakin]

(In reply to comment #4)
> That is, pushing that and not changing nsDOMEvent at all.
> 

Not sure what you mean. The user input state from ExecuteMenu is being pushed. Or do you mean there is a way to push the popup blocking state directly?

Comment 6

[pal-moz]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072323 Minefield/3.0a7pre ID:2007072323

seems to be fixed.

Comment 7

[Jeff Walden [:Waldo]]

Probably already there, but just to confirm...

Comment 8

[Adam Guthrie]

Say hello to: http://litmus.mozilla.org/show_test.cgi?id=4007.

Comment 9

[Adam Guthrie]

Marking this as VERIFIED per comment 6.