New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 131 users

Issue metadata

Status: Duplicate
Merged: issue 38458
Owner:
Closed: Jul 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Blocked on:
issue 38458

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Don't play plugin instances inside suppressed popups?

Project Member Reported by pkasting@chromium.org, Oct 16 2008 Back to list

Issue description

Had a report from a user who was very confused that he kept hearing audio; 
it turned out he had a flash ad (with sound!) inside a constrained popup.

Perhaps we could not instantiate (or not start, or whatever) plugin 
instances inside constrained popups (on unconstrain, start the instance 
immediately).  It's not clear to me whether a better theoretical fix would 
be "muting" constrained popups, but it's moot since that's technically 
infeasible.
 

Comment 1 by jon@chromium.org, Oct 21 2008

Status: Assigned (was: NULL)

Comment 2 by paiva...@gmail.com, Nov 3 2008

As example of this issue can provide the link to http://www.cnbc.com/. It's self-
refreshing site and on some refreshes it opens popup with cnbc video automatically 
starting. Thus if page is open in background it's very hard to understand where 
sounds are coming from especially because the "Blocked Popup" line is hardly seen on 
this site (because of colors and styles used on this site).
I'd suggest to not execute any JavaScript and any plugins from blocked popup windows.
And if you have a video (silverlight / flash within a popup)
http://www.microsoft.com/VIRTUALEARTH/

Click on big huge image header ( See It In Action ) and the sound, video will be 
playing hidden in the popup.
Status: Available (was: NULL)
I just ran into this.  With several browser windows open all with multiple tabs, 
suddenly my headphones were invaded with some audio from an advertisement. I couldn't 
for the life of me figure out where it was coming from!  It wasn't until I took a 
stab in the dark and closed the little RHS popup notice window that it stopped.

Generally, I listen to music on my PC while working and really dislike being 
interrupted by unexpected active content--especially audio. The kind of in-your-face 
advertising out there that blasts the user without regard for their preferences or 
consent is in really bad taste, but can't we do something about it? If there was a 
'mute' button for the browser, I'd use it.



Labels: -Area-Misc Area-BrowserBackend Fixit

Comment 7 by gke...@gmail.com, Jul 25 2009

Also to note that JavaScript seems to be processed in popup which would be nice to 
block also.  See  Issue 17640  for test cases.
 Issue 17640  has been merged into this issue.
This is for blocking js from 17640

1. Goto Popup Blocker test web page 
(http://www.popupcheck.com/freescan/popup/popup_test_standard.asp)
2. Click on the "Click here to START the pop up test" 

Comment 10 by dhw@chromium.org, Nov 17 2009

 Issue 27942  has been merged into this issue.

Comment 11 by dhw@chromium.org, Nov 25 2009

 Issue 28697  has been merged into this issue.
I've also come across this.
Surely if the popup is blocked it shouldn;t be rendered AT ALL until selected from 
the blocked 'menu'.
This could lead to malicious plugins or javascript running when the point of the 
blocker is to stop the page completely.
I think this needs to be reclassified as security/bug rather than feature.

Comment 14 by oritm@chromium.org, Dec 17 2009

Labels: -Area-BrowserBackend Area-Internals
Labels Update:

Replace Area-BrowserBackend by Area-Internals

Comment 15 by dhw@chromium.org, Jan 23 2010

 Issue 28482  has been merged into this issue.

Comment 16 Deleted

Really blocking popups causes far more problems, since then sites cannot properly 
script their popups, causing sites to break and not be fixed by users "showing" the 
popups.
Perhaps this is a question of ignorance...  How does IE/Firefox block popups?  (I 
assume they prevent the scripts from loading inside [hence no audio/security problems] 
but allowing popups will fix all sites that I know of...)  Do they run popups in the 
background as well?  I may just not fully understand the last comment by pkasting and 
how blocking popups causes problems since I generally dislike them (especially ads with 
audio)
I have to agree with classifying this as a bug rather than a feature.

To an end-user wondering where that particularly annoying smiley advert ("HELLO!") or 
the even more annoying 'swat that mosquito advert' ("buzzzzzzzz") is coming from (as 
there is no recognisable source of the noise) just to find it in a constrained pop 
up, this is not a "feature to be added" but a "big annoying bug" as "no other 
browsers have this problem".


Regards, Phil
This article from microsoft KB has details about IE's popup blocker:
http://msdn.microsoft.com/en-us/library/ms537632(VS.85).aspx
I would agree this is a bug not a feature.  Muting the popup does not remove the 
malicious script in the pop up.  Perhaps there is a bigger picture with those 
developing Chrome about popups (which I hope they would be willing to express here if 
there is); and independent of my position on Microsoft, I believe their approach to 
popup blocking the safest for the end user and the most difficult to be hacked (in the 
sense that if the js doesn't open the window, whatever is in the window cannot load).  
Just my opinion (and what I believe others have been voicing), but I don't know nearly 
enough coding to even attempt to try to change it...
I have seen a few websites which use a script in a popup to track a user's activity on 
a site.

Does Constraining these popups without stopping their scripts allows the users' 
activity to be tracked without the user realising?
Logically speaking, I would assume so.  My understanding of Chrome's current popup 
blocker is that it holds it in the corner without actually allowing it to open a new 
tab without actually stopping the scripts from running.  (Maybe a little simplistic, 
but currently flash, js, etc. runs even though it is blocked, so a script to track user 
activity I would ).  Perhaps Chrome has implemented something, any responses from 
someone who actually knows instead of my conjecture?  :)

Comment 24 by dhw@chromium.org, Jan 26 2010

 Issue 33166  has been merged into this issue.
The sites that were indicated as containing an audio-playing popup (CNBC, Microsoft 
VitualEarth) do not have it now. If you want other links, where you can currently see 
the problem, here they are:

http://www.salmoiraghievigano.it/portale/out/homePage.aspx
http://www.paganella.net/
A new problem with the new popup blocker is that you can't close the popup after it's 
been blocked so if it has sound, the sound keeps playing until you navigate away from 
the page.  While I believe the underlying problem is playing popups even when they are 
blocked, not being able to close them when they make sounds because they are running is 
extremely frustrating.

Comment 27 by prog...@gmail.com, Feb 10 2010

maybe now that content filtering was implemented its code can be used to block plugins 
from blocked popups
@26: You can close them: open the popup, then close it.

But really we need to fix the underlying issue.

Darin was telling me in his office two weeks ago how easy it would be to solve this 
class of problems, so assigning to him :D.
 Issue 16762  has been merged into this issue.
 Issue 36065  has been merged into this issue.

Comment 31 by darin@chromium.org, Feb 18 2010

Summary: Don't play plugin instances inside suppressed popups? (was: NULL)

Comment 32 Deleted

Comment 33 by phistuck@gmail.com, Mar 10 2010

This is definitely a bug and not a feature... starting Chrome with the option to show 
my last tabs on and a constraint popup that has a sound is quite simply a bad user 
experience.
Having sounds from literally nowhere (since the popup was "blocked"), is a bad user 
experience and a truly unexpected one.
If the sound is loud, not only can it scare the user (happened to me a few times 
already), but also disturbs the surroundings.

And the fact that scripting is allowed, causes the website\popup website to track 
users even when it was *blocked*. This is bad. Really, really bad.
Blockedon: 38458
This issue is also bothering me. Some sites have popup that leads to malicious site 
where unwanted js code was executed. On top of that, the flash popup that contains 
sounds were playing in the background. 

I read over the comments above. A solution shouldn't be that hard to come up and get 
implemented. First, change the behaviour of popup blocker where it will block popup 
completely and not render it at all. Then have one of those "drop-down" information 
bars, same one as the "save password?" thing, asking users if the main page is not 
rendered correctly and if they want to add the current site to the "allow popup 
list". 

Or implement a black list will work too if chromium team is worried about impacting 
average users' user experience. So have a super duper black list allow user to input 
urls and any popup that is detected is not download/render at all in the first place.  
@darin - Can you fix these "easy class of problems" (comment 28) for us please? :P

Comment 37 by phistuck@gmail.com, Apr 17 2010

How about, giving the user a chance to load the popup, by blocking the JavaScript of 
the opener page for a few seconds? If the user loaded the popup after, say, five 
seconds, the window.open function would return a window. Anything longer than that - 
the opener will get NULL (or whatever it is getting when the popup is not opened due 
to popup blocking).
It makes sense, I believe, because if the user clicked on something in order to open 
a popup and it was blocked (which is not supposed to happen, I believe, but it does 
happen sometimes), the user would go on and unblock that popup pretty immediately (5 
seconds count as "pretty immediately", in my opinion).
If the popup was automatically opened (meaning, not following a mouse click), it 
could be important (for example, the alerts in Outlook Web Access, or an automatic 
options dialog), or it could be a commercial (and more commercials may follow 
afterwards). That way you are protecting both of the website and the user.
Having a blocked popup that has lost connection with its opener before it was opened 
can lead to incompatibilities, which is why (I guess) Internet Explorer reloads the 
whole page after you allow popups to open.
And, generally, if it is a cross origin popup, what can the host page do with the 
window returned from the window.open? If nothing (I think so), I believe we can 
simply not load the popup and get it over with, since it is not like the opener can 
do anything with it.
One thing they can do is use the new cross-origin postMessage API. I'm pretty sure 
nothing else is possible due to the same-origin policy. Just throwing that out there.

P.S. I doubt very many websites are using the postMessage API, though that usage may 
increase in the future.
Labels: Feature-PopupBlocker Feature-Privacy
This issue is from October 2008 and really should be fixed.

I just had an issue with a web app that was failing to see that a popup was blocked.
I fixed the detection using:
if (!win || (win && win.document && win.document.body && !win.document.body.clientWidth))
{
    goPopupBlocker();
}

Also, when the popup is constrained the users allocated time using the app begins.
Surely as a security issue this should be fixed quickly?

Mike Ratcliffe
How is what you describe a security issue?
I was not very clear ... a number of previous posts claimed that this is a security
issue and I was referring to those posts. My post was to illustrate that hiding
windows instead of blocking is very bad when it comes to using complex web apps in
Chrome.

But as to why it would be a security issue ... I have attached a test case that
illustrates the shortcomings of the hidden popup method.

If you run the attached test you will see that popup windows that are only hidden
have access to variables and methods in the opener ... this means that they can grab
values from pages (e.g. credit card numbers) and submit them to another server (via
image url with params, iframe, XHR etc.)

From a frontend developers perspective hiding popups is bad because:
1. It is more difficult to check if the popup was "blocked"
2. Popups, confirm prompts, alerts etc. that may have been displayed onload are
hidden from the user.
3. Video, audio and other embeds are running in a hidden window
4. There are millions of situations where hiding as opposed to blocking a popup is
bad. Opening a popup is often part of a process in complex web apps and this can be
devastating from a users perspective. As an example a student runs an online quiz but
the popup is blocked. Believing that the quiz has not started he does something else
instead. When the user goes back to his computer and realizes that the quiz was
blocked he tries again but he will have to pay to do the quiz again because it costs
money for each run. 

In summary, malicious scripts can be executed in hidden popups but not in blocked popups.
Chrome popup tests.zip
1.7 KB Download
Comment 42, you really don't belong here. You can oppose popup hiding at  Issue 38458 . 
You can protest the difficulty of noticing popups that have been hidden at  Issue 39260 . 
Your security argument sucks; javascript can be run irrespective of whether it's 
contained in a popup, and the javascript privileges that popups should have should be 
independent of whether the browser thinks the popup should be blocked. Popup blocking 
is a tool for user convenience and annoyance reduction, not privacy or security.
I think the main point is that as a pop-up BLOCKER it should actually BLOCK the pop-up 
not just load and run it but hide it, which as a method is completely stupid.

Even the old google toolbar , and every other pop-up blocker and other browsers, blocks the 
popup better than chrome.
No, that's the main point of  Issue 38458 .

Comment 46 Deleted

Comment 47 by mal@google.com, May 4 2010

 Issue 32567  has been merged into this issue.
 Issue 43591  has been merged into this issue.
 Issue 43668  has been merged into this issue.
 Issue 43947  has been merged into this issue.
Mergedinto: 46316
Status: Duplicate (was: NULL)

Comment 52 by dhw@chromium.org, Jun 16 2010

Mergedinto: -46316
Status: Available (was: NULL)

Comment 53 by dhw@chromium.org, Jun 16 2010

 Issue 46316  has been merged into this issue.
 Issue 47814  has been merged into this issue.

Comment 55 by mkte...@gmail.com, Jul 24 2010

 Issue 50108  has been merged into this issue.
Hi, I am experiencing the same problem.  I also strongly suggest treating this as a "bug" and not a "feature request" -- the user experience is very very VERY bad when the blocked popup plays ghostly audio in the background.

http://beta.kyte.com/mig/ChromePopupBlockerBug.html

Our web video player (a-la-hulu) has a "popout" feature that launches a popup with the video player set to 100% within it.

Unfortunately, when the popupblocker prevents the popup, it still instantiates the Flash player and the video starts playback in neverland.

When the confused user hits the button multiple times, as confused users are wont to do when their action doesn't give any obvious feedback, multiple pages are instantiated and multiple copies of the video start playing.

This makes an audible mess out of the user's speakers.  This makes my customers think that our product is "broken on Chrome" and we have to tell our customers that, actually, "chrome is broken on popups."

Comment 57 Deleted

Labels: Restrict-AddIssueComment-Commit
Another possible option for fixing this particular issue without fixing  bug 38458  is the approach discussed in  bug 71216  for preload.
 Issue 72052  has been merged into this issue.
 Issue 72725  has been merged into this issue.

Comment 62 by mkte...@gmail.com, Mar 14 2011

 Issue 76058  has been merged into this issue.
Labels: -Fixit bulkmove TaskForce-Fixit
Had a report from a user who was very confused that he kept hearing audio; 
it turned out he had a flash ad (with sound!) inside a constrained popup.

Perhaps we could not instantiate (or not start, or whatever) plugin 
instances inside constrained popups (on unconstrain, start the instance 
immediately).  It's not clear to me whether a better theoretical fix would 
be "muting" constrained popups, but it's moot since that's technically 
infeasible.

Comment 64 by dhw@chromium.org, Apr 2 2011

 Issue 36844  has been merged into this issue.
 Issue 78643  has been merged into this issue.
 Issue 82637  has been merged into this issue.

Comment 67 by dhw@chromium.org, May 21 2011

 Issue 82396  has been merged into this issue.
Owner: bauerb@chromium.org
Status: Assigned (was: NULL)
 Issue 78097  has been merged into this issue.

Comment 70 by mkte...@gmail.com, Jul 11 2011

 Issue 88856  has been merged into this issue.

Comment 71 by dhw@chromium.org, Jul 27 2011

 Issue 90377  has been merged into this issue.

Comment 72 by dhw@chromium.org, Aug 4 2011

 Issue 91212  has been merged into this issue.
Labels: -Pri-3 Pri-2 Mstone-17
Our pipeline for M15 and M16 is full, scheduling this for M17 for now. Definitely something we want to resolve.

Comment 74 by dhw@chromium.org, Nov 21 2011

 Issue 104944  has been merged into this issue.

Comment 75 by k...@google.com, Dec 19 2011

Labels: -Mstone-17 Mstone-18 MovedFrom-17
Moving bugs marked as Assigned but not blockers from M17 to M18.  Please move back if you think this is a blocker, and add the ReleaseBlock-Stable label.  If you're able.

Comment 76 by kareng@google.com, Feb 7 2012

Labels: MovedFrom18 Mstone-19

Comment 77 by bau...@google.com, Mar 6 2012

Cc: bauerb@chromium.org
 Issue 117031  has been merged into this issue.

Comment 78 by laforge@google.com, Mar 27 2012

Labels: -Mstone-19 Mstone-20 MovedFrom-19
Labels: -Mstone-20 Mstone-21 MovedFrom-20
M20 is about to sail. If this still need to be part of M20, put them back and add release block label.
 Issue 130061  has been merged into this issue.
 Issue 149816  has been merged into this issue.
how's that blocked on 38458? If 38458 is fixed, this issue will just not exist anymore, right?

Mark as duplicate instead?
It's not a dupe because they're not the same bug and they're not the same proposed solution.

You are right that if we implement that bug, this one will disappear.
Project Member

Comment 84 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Feature-PopupBlocker -Feature-Privacy -Mstone-21 Cr-Privacy M-21 Cr-Internals Cr-UI-Browser-PopupBlocker

Comment 85 by laforge@google.com, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Comment 86 by dhw@chromium.org, Jun 23 2013

 Issue 250218  has been merged into this issue.
Mergedinto: 38458
Status: Duplicate (was: NULL)
Duping out since we plan to not render/run content in suppressed popups.

Sign in to add a comment