396332 - Popup window address not displayed for flash popups

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, defect, P5)

Description

[Per Eriksson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

When a flash movie is creating a popup and popups from the site is not allowed, the yellow popup information bar is displayed but with no address what the address to the popup window is.

That is, the row "Show 'http://popup.address/'." row is not displayed when clicking on the button in the popup information bar.

Reproducible: Always

Steps to Reproduce:
1. Go to: http://www.prada.com/
   It's a flash fashion site.
2. Click on the "FALL/WINTER 2007" link with the pdf icon.
Actual Results:  
The popup information bar appears, but with no "Show 'http://popup.address/'." menu item when clicking the "Preferences" button.

Expected Results:  
The row "Show 'http://popup.address/'." is present at the bottom of the menu after clicking the "Preferences" button.

Comment 1

[zug_treno]

Reproducible with https://bugzilla.mozilla.org/attachment.cgi?id=205245 and Firefox 3.0b2.

See also Suite bug 409671.

Comment 2

[Mike Shaver (:shaver emeritus)]

Attachment: patch to pass the incoming URL into win->Open

The problem here is that nsDocShell::InternalLoad always calls win->Open with an empty URL.  This trivial patch fixes the issue, but hasn't otherwise been tested.

I believe that the difference between the plugin case and the in-page case is that the former is posted asynchronously and the latter just directly calls ::Open with the right args, but in the plugin case we're using an implicit creation of a new window through the target argument.

Comment 3

[Mike Shaver (:shaver emeritus)]

Moving to a better component, and cc:ing Christian and Boris for their wisdom.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So this will start a load in the new window and then start another load immediately in the same window?  That _might_ be OK now that javascript: is executed asynchronously, perhaps...  But it worries me greatly, especially at this point in the release cycle.

That said, this is not Flash-specific, right?  The same thing happens for targeted links?

Comment 5

[Mike Shaver (:shaver emeritus)]

I don't know about targetted links; I think they tend to be permitted because they happen during a user click, but I could check with a synthesized .click() on a targetted link.

What could I check to detect that I don't need to do the same load again?  I am game for anything!

Comment 6

[Boris Zbarsky [:bzbarsky]]

I think you more or less have to do the load from this code no matter what: otherwise you'll end up with the wrong referrer, etc.  Ideally, we'd have a way of communicating the URI that should show up in the popup blocked event to the global window code without having that code actually try to load the URI.  Perhaps an API addition to that effect on nsIDOMWindowInternal or something?

Comment 7

[Mike Shaver (:shaver emeritus)]

Sure, add an intendedURL parameter do nsIDOMWindowInternal::open, and pass it through?  You think that's 1.9-safe, in the absence of a plugin test harness to check this case?  (If synthesized link.click() works, that would be OK too.)

Comment 8

[Boris Zbarsky [:bzbarsky]]

I think that's safer than changing the existing window.open() call, for sure.  It should be pretty safe in general, in my opinion.  I do think that the targeted link.click() case can in fact be used to test this.  So can targeted form.submit().  All of those go through this codepath.

Comment 9

[Boris Zbarsky [:bzbarsky]]

So fwiw, we don't have click() on links.  You can dispatch trusted events using UniversalXPConnect code from onload or a timeout, but I'm not sure what the popup state will be in that case...  Given the existing mochitests that test window.open(), I wonder whether popup blocking is even enabled in mochitest.  :(

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 11

[u597032]

Flash is no longer supported