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 1121 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Blocking:
issue 76571
issue 90841

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

The absence of synchronous message API make impossible to pass options to scripts that are loaded before the page to block content.

Reported by eburszt...@gmail.com, Sep 2 2010

Issue description

Chrome Version       :  5, 6, 7


With the current implementation of the message system it is impossible to have an extension that blocks content based on user options/choices because there is no way to either :
- load options in content script synchronously
- Ask the background page if it is okay to load the content.

Accordingly there is no way to block/ analyze content before it hit the page, which makes any security /content blocking extension ineffective. On a side it will also affect how to use the experimental Network API because similarly you can't use it in conjunction with user options.


Here is a description of  two most "reasonable" way I came up with and why they are not working

Plan A: Try to use the chrome.extension.sendRequest API to load the options or query the background page. This is done by :

1. Creating an extension that injects a script before the page is loaded by specifying "run_at": "document_start"
2. Try to have it fetch option from the background page by calling the chrome.extension.sendRequest() API
3. The callback will be returned during the loading phase, so the first elements are not analyzed.

This fail because the call is asynchronous.

Plan B: Try to inject programmatically the script at loading time by adding the listener:     chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab) 

This is achieve by :
1. Adding the listener chrome.tabs.onUpdated.addListener to the background page
2. Use it to inject the script at loading time by checking the status:  if(changeInfo.status == "loading") 
3.The script will be executed at the end of the loading (according  to my test on localhost). So the
event handler document.addEventListener("beforeload",,) is completly useless. 

I am not sure why it failed, my guess is because the injection is done asynchronously.

Safari faced the same issue with their plugin API and they decided to solve it by implementing the synchronous method: safari.self.tab.canLoad(event, myMessageData); See http://developer.apple.com/safari/library/documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html (section :Blocking Unwanted Content)


It is possible to have the same method or a way to ask for a synchronous message ? Without it there is no way to write an extension that let user tweak the content they want to load.


 

Comment 1 by eroman@chromium.org, Sep 21 2010

Labels: -Area-Undefined Feature-Extensions
I too would like to see some form of a synchronous messaging API for content scripts so that I don't have to maintain a big work around in the NotScripts extension by temporarily caching settings in the HTML5 local storage for every site a user visits. This method overcomes the limitations of the asynchronous messaging API but then it then requires encryption and for the user to hard code a password in the extension's folder on every update.

I know that having a synchronous messaging API in a content script can lead to performance degradation if an extension abuses the feature by making too many synchronous requests. Perhaps there could be a quota of say 10 synchronous messaging requests for an extension on each page load. This would maintain the high level of performance of Chromium/Google Chrome.

Comment 3 Deleted

Comment 4 Deleted

I think this issue is somewhat  similar to  issue 35897 .
They have some limitation to success blocking content. Chrome has being weak in content blocking since it was born. It leads to some security /content blocking extensions (adblock,adthwart,notscripts...etc)less effective and unhandy to use. Yeah, security  is important to chrome,but ease of use for users is also indispensable. Maybe we need to strike a balance.
No it is not similar to  issue 35897 :  this issue was about being able to remove an element before it is loaded and this has been solved.

This issue is about the fact that you can't query user preference before loading an element before you don't have a synchronous method for this. 

This synchronous method exist for Safari (safari.canLoad) so there is no reason to not get one for Chrome.


Comment 7 by ytku...@gmail.com, Sep 29 2010

i agree with everyone here i think we can all benefit from this. 

Comment 8 by finnur@chromium.org, Sep 30 2010

Labels: -Type-Bug Type-Feature Mstone-X Area-Internals
Status: Available
I too look forward to this functionality.

Comment 10 by ytku...@gmail.com, Oct 6 2010

yes please add this functionality

Comment 11 by Deleted ...@, Oct 9 2010

I have thoroughly enjoyed Chrome, but the fact that I cannot use some of the extensions that keep my computer clean, such as noscript in Firefox, are the only thing that keep me using those browsers. They are slower, and not as responsive, but they are safer, because I am able to have these extensions. If this one change will make it so that I can finally make the switch, please do implement it.
I agree. Anything that makes NoScript-like extensions work better in Chrome makes Chrome that much better to me.

Many websites seem to use JavaScript simply to annoy people, under the assumption that throwing around flashy effects means you're a professional. It's almost like early 90's web design all over again. Sometimes these sites aren't easily avoided either, as sites like Facebook, MySpace, and yes, even Google, can make these mistakes.

If this issue could be solved, it would mean a better user experience for those who wish to avoid these issues, and therefore people will be that much happier with Chrome, and more likely to use it as their main browser.
the sooner this bugs gets fixed the more experienced people will switch from firefox to chrome and the more experiencen people will guide noobs to use chrome.
im currently using ff 4 and chrome daily on ubuntu 10.10

Comment 14 Deleted

Why do you tie the hands of extension developers like that?

Please include this
I use NotScripts, but it is hindered by this bug.  Also, it's another advantage that Firefox has over Chrome.

Please fix this.

I like the comment made by optimalcycling:

"I know that having a synchronous messaging API in a content script can lead to performance degradation if an extension abuses the feature by making too many synchronous requests. Perhaps there could be a quota of say 10 synchronous messaging requests for an extension on each page load. This would maintain the high level of performance of Chromium/Google Chrome."

Comment 17 by amiag...@gmail.com, Oct 29 2010

There is no "canLoad" quota in Safari. If you have a quota, then injected scripts have to load all the data needed to make decisions, which means much higher memory use (data amount times each script times each tab times each frame in each tab).

You will only have performance degradation with badly written extensions, and that's going to happen regardless of whether you have a usable synchronous communication channel.

One thing Safari does do is limit "canLoad" calls to "beforeload" events. If you don't provide a legitimate "beforeload" event, you can't use "canLoad".

Anyway, this functionality is needed by security and privacy extensions.

Comment 18 by kolez...@gmail.com, Oct 31 2010

I add my voice in favor of fixing this. Absence of a comfortable content control is what prevents me currently from a switch to Chrome.

Comment 19 by Deleted ...@, Oct 31 2010

Please fix!

Comment 20 by Deleted ...@, Nov 2 2010

Yes, please fix this 

Comment 21 by Deleted ...@, Nov 6 2010

I am looking forward to see this function work!

Comment 22 by osg...@gmail.com, Nov 6 2010

You know, there's the voting mechanism in every bug (the star) that you can use to express interest in seeing a resolution.

Adding an idiotic "me too" "yes, please" to these issues is a waste of time and counterproductive.

This may be solved by exposing the sleep() function through the chrome.extension API. While it does not automatically make the calls synchronous it allows the developer to wait until an asynchronous call has completed before moving on. Furthermore, using the permissions system the browser could display a warning that extensions requesting access to the sleep function may cause an additional delay when loading pages.
@Josh: This is more a hack,  the Safari canLoad function is the way to go. If Apple can do it for Safari there is no reason that we can't have it in Chrome. Actually there is a ton of the experimental API which need a synchronous modification. Eg header modification which will need to be synchronous.


Ps: Please Star the isssue so it keep rising in the priority list.


Please fix this issue, we need full script blocking ability
this feels like a dup.  Matt, is there a better bug to dup this against?

Comment 27 by Deleted ...@, Nov 13 2010

This would be a very good capability to support.
The closest I can think is  issue 30224 . If content scripts could access the extensions local storage, that seems like that would solve the main problem here.

Comment 29 by mjun...@gmail.com, Nov 22 2010

Please add this feature!

Comment 30 by Deleted ...@, Nov 27 2010

A fix on this would be greatly appreciated.

Comment 31 by lazy...@gmail.com, Nov 29 2010

Definitely needed.  There is no way I want all the scum of the web able to come onto my system before I can kick them out.  

Comment 32 by w4mw...@gmail.com, Nov 29 2010

Please fix this bug. I don't want to resort to returning to the slow firefox!!
Labels: Restrict-AddIssueComment-Commit
We appreciate the enthusiasm, but in general lots of "me too" comments only clutter the bug report.  If you want to vote it up, simply star the bug.
Cc: battre@chromium.org
Cc: nepper@chromium.org
Labels: -mstone-x
Blocking: 76571

Comment 38 by mkwst@chromium.org, Jul 28 2011

Blocking: 90841
Cc: jsc...@chromium.org
Cc: asargent@chromium.org
After polling a few people I have a suggestion on how to best handle this. The problem with allowing content scripts to load synchronous settings is that they will block the main thread (including every document in the renderer) and potentially cause hard to identify slowdowns. So, how about we just give content scripts an API to pause loading temporarily, but with a maximum timeout? That would give the callbacks time to perform their asynchronous operations and then resume page loading. Meanwhile, the suspended page won't be blocking the main thread and delaying other documents in the same renderer.

I'm picturing a content script API like this:

  chrome.extension.pauseLoad(timeout_callback)
  chrome.extension.resumeLoad(resume_callback)

So, a content script can call pauseLoad and optionally pass a callback if the pause times out and page loading is resumed (I figure we should make the timeout amount cumulative and fixed, rather than user controlled). Assuming the normal situation where everything finishes on time, the content script will call resumeLoad and optionally pass a callback that is executed immediately before the loading resumes.

Any thoughts?

Comment 41 by pam@chromium.org, Jan 16 2012

Cc: pam@chromium.org

Comment 42 by aa@chromium.org, Jun 28 2012

Status: WontFix
I think the storage API takes care of many of the use cases here:

http://code.google.com/chrome/extensions/storage.html

In general, it's inconsistent with Chrome's performance goals to have a synchronous messaging API, so I'm wontfixing this.

Comment 43 by aa@chromium.org, Jun 28 2012

Actually, I'm sorry, I don't think the storage API helps too much here because it's async.

This proposal is still inconsistent with our performance goals, so we'll have to find other solutions. One such solution is the declarative web request API: 

http://code.google.com/chrome/extensions/dev/declarativeWebRequest.html
 Issue 135095  has been merged into this issue.
Project Member

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

Blocking: -chromium:76571 -chromium:90841 chromium:76571 chromium:90841
Labels: -Feature-Extensions -Area-Internals Cr-Platform-Extensions Cr-Internals

Sign in to add a comment