Closed Bug 343175 Opened 14 years ago Closed 14 years ago
Blocked popups requested by subframes inherit the security context from the top-level document when showing them. This causes some troubles if the top-level document and subframes are served from different domains. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsGlobalWindow.cpp&rev=1.863&mark=4206-4209,4216,4218-4220,4258#4200 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/browser.js&rev=1.654&mark=542-546,555-566#540
this testcase is depending on bug 343168 to make up a mixed document. popupblocker needs to be enabled. works on: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3) Gecko/20060629 BonEcho/2.0a3 Mozilla/5.0 (Windows; U; Win98; en-US; rv:22.214.171.124) Gecko/20060629 Firefox/126.96.36.199
Hmm... I'm not sure why we use the top window, here, exactly. Are there some sort of reasons the popup blocker UI needs that data? If so, we should be passing more data around, sounds like.
at cenzic we used all the information from the popupblocked event and more in order to get work done. please contact colin before breaking this too badly.
Assignee: dveditz → jst
Flags: blocking188.8.131.52? → blocking184.108.40.206+
timeless, my point was that if the popup blocker needs the originating window, then that window should be a member of the popup blocked event...
Attachment #229581 - Flags: review?(mrbkap) → review+
Attachment #229581 - Flags: superreview?(bzbarsky) → superreview+
Fix checked in.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 229581 [details] [diff] [review] Fix. Make the requesting URI be that of the window on which open() was called. a=dbaron on behalf of drivers. Please check in to MOZILLA_1_8_BRANCH and mark fixed1.8.1 once you have. (Did the reviewers mention NS_STATIC_CAST?)
Attachment #229581 - Flags: approval1.8.1? → approval1.8.1+
Comment on attachment 229581 [details] [diff] [review] Fix. Make the requesting URI be that of the window on which open() was called. approved for 1.8.0 branch, a=dveditz for drivers
Attachment #229581 - Flags: approval220.127.116.11? → approval18.104.22.168+
Fixed on the 1.8.0 branch.
v.fixed on both branches: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:22.214.171.124) Gecko/20060906 Firefox/126.96.36.199 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b2) Gecko/20060907 BonEcho/2.0b2
interestingly, the behaviour on 1.0.x is upside-down. With the patch I get bugzilla cookies displayed, without the patch, something else.
You need to log in before you can comment on or make changes to this bug.