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

Issue 242710 link

Starred by 7 users

Issue metadata

Status: Duplicate
Merged: issue 242890
Owner: ----
Closed: May 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Userscripts aren't working for iframe anymore.

Reported by hasano...@gmail.com, May 21 2013

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36

Steps to reproduce the problem:
1. Install this sample userscript,
 https://dl.dropboxusercontent.com/u/39457223/google/frame.user.js
2. Open this page,
https://dl.dropboxusercontent.com/u/39457223/google/index.html

What is the expected behavior?
Userscript is expected to be also work for frames.

What went wrong?
Chrome doesn't allow userscript to work in iframes.

Did this work before? Yes Before version 27.0.1453.93 m

Chrome version: 27.0.1453.93  Channel: stable
OS Version: 6.0 (Windows Vista, Windows Server 2008)

Three alerts are expected in index.html, but only get one.
If you open iframes in a new tab, you will see that userscript works in self page.

https://dl.dropboxusercontent.com/u/39457223/google/frame1.html

But when It's embedded, than not working anymore.
 

Comment 1 by tkent@chromium.org, May 22 2013

Labels: Cr-Platform-Extensions

Comment 2 by rstbro...@gmail.com, May 22 2013

This problem is also present with frames. For example, a page structured as: www.example.com/main.php, consisting of two frames "www.example.com/menu.php" and "www.example.com/content.php" will only have the userscript run on main.php, when previously you would be able to include "content.php" and "menu.php" in your include globs and have the script run on those frames when "main.php" was loaded.

Is this caused by the recent security tweaks? I can understand not allowing cross domain inclusion, but if the frames are on the same domain should this really be blocked?
I guess the default behavior on Content Scripts is just catching up with User Scripts. Currently, the "all_frames" setting of a content script (within an extension) defaults to false, meaning it will only be executed on the top frame. So, I suspect this will be flagged as "it is working as intended now" and put away.

A nice solution would be to support some additional meta-attributes that we can use to specify things like "@all_frames true" but with Chromium's track record regarding user scripts support I don't see that happening anytime soon.
Cc: rdevlin....@chromium.org yoz@chromium.org
Status: Available
yoz@, rdevlin.cronin@, is this your area of ownership?

Comment 5 by yoz@chromium.org, May 23 2013

Mergedinto: 242890
Status: Duplicate

Sign in to add a comment