-
Notifications
You must be signed in to change notification settings - Fork 83
Necessary script in frame not shown in matrix #215
Comments
Yes, it was. I was able to reproduce it just a minue ago. Strange that |
I tried on Chromium 33. I will have to try on something closer to what you use. Is it Chrome? Version, etc. Is smart-reload enabled? Any other add-ons? When the bug occurs, can you see the requests for scripts in the Statistics tab? |
I'm on Chrome 33.0.1750.152 under Kubuntu 13.10. Smart-reload is enabled. I tried it also with all other add-ons disabled and Chrome restarted - the script cell for compass.pressekompass.net remains empty even after whitelisting the frame cell. In the statistics tab I can see some allowed scripts like: http://www.spiegel.de/politik/deutschland/pressekompass-zum-afd-parteitag-bernd-lucke-unter-druck-a-960345.html{inline_script} but no blocked scripts referring to pressekompass.net. EDIT: Adblock complex rules are enabled, and I'm using most block lists. ABP rules only block some png's and gif's on that site, though. |
Ok, I still can't reproduce using Chrome. There is a hint in there though. You see only 3 scripts reported eventually, while I see 4 reported right away. The proper number is actually 4, 3 external javascript files + 1 for the inline javascript. The only way that inline javascript is counted is through the injection of a content script, which looks for An extension's content scripts is executed in the page context, so that if you bring up the console for that page, you should be able to see the output of any error from the content script, which can be identified by the source file in which the error occurred: if the content script failed, an error in the file |
Looking at the code, I think I see a mistake. If so, such bug would show up depending on how fast a page loads (depends on computer, network, etc.)... At line #217 of contentscript.js, I suspect the code should be
instead of
Since I can't reproduce the bug, would you mind trying the above change to see if it resolves the problem? EDIT: Looking more into this I doubt there is a bug in the code above, but I guess it should be ruled out by trying the change just to be sure. |
Unfortunately the change in line #217 didn't help. In the console I found this: And there is an entry that says: Uncaught SecurityError: Blocked a frame with origin "http://www.spiegel.de" from accessing a frame with origin "null". The frame requesting access has a protocol of "http", the frame being accessed has a protocol of "data". Protocols must match. (Sorry, I was not able to upload an image: "Something went really wrong, and we can't process that image." I don't know why.) |
I'm really puzzled at this point, there seems to be something specific in your environment which prevent HTTPSB's own content script from running properly, or from running properly but where |
The only one I can think of is Tampermonkey. But as mentioned earlier, I had disabled all other add-ons (and I've done it for Tampermonkey again) but the problem persists. BTW, there is one entry that says: event.returnValue is deprecated. Please use the standard event.preventDefault() instead. javascript-V5-0-3.js:26 Don't know if that's somehow relevant. |
I installed Tampermonkey, and I confirm the above reference to |
Sure, it's this one: http://userscripts.org/scripts/show/158054 However, as mentioned before I had disabled all extensions (except |
Do you have "Predict network actions to improve page load performance" in Settings? There is an instance where the content scripting handler would fail accounting for script tags on the page, is if the tab id is negative, which means in such case HTTPSB wouldn't know where to the found script tags are to be recorded. I believe tab id of -1 is possible if a page is premptively fetched. I'm speculating here about how this works internally in the browser. |
Yes, it's enabled here. However, after disabling it the problem remains. |
Since I can't reproduce it, the only way for me to investigate I can think of is to provide you with a debug version of HTTPSB's files |
EDIT: Never mind. I slightly re-wrote the code in there which results in the exact same behavior you are describing. I will investigate further. |
Alright, I believe this could fix the issue, but since you can reliably reproduce it, only you at this point can validate this fix, if you don't mind. Replacing all this at line #217 of contentscript.js:
with just
I believe should fix the problem. In effect, HTTPSB's content script wasn't being executed in your case. |
|
I don't know why the content script does not get executed. The change I proposed should have made HTTPSB's content script unconditionally execute. I installed Debian-based Chrome itself here, and still unable to reproduce. Something is preventing the content script from running, and I just can't find out without first reproducing the bug, so that I can walk through the code. Did you try on another computer? |
I just tried Chrome in Manjaro Linux running in Virtualbox. Same problem :-( I tried a second time after editing contentscript.js as suggested by you Raymond, I don't want to keep you from more important work. The problem |
Could you confirm that the property No reason why it should be otherwise, but I am at a lost to understand what is happening.
Unlikely I will be able to not worry about this problem. This is pretty serious, as the bug here causes the user to be misinformed, hence he can't take proper action as a result of this misinformation. It's more likely that other people are also suffering the same problem, but not realizing that there is missing information. |
|
BTW, I've noticed this side-effect also on other sites. |
Now this is just plain weird. The API doc clearly says that when a content script is injected at Would you mind if I send you a custom version of That would be the content of
|
No problem, I'll do that. However, I'm about to leave now so I won't find the time until tomorrow evening. I'll report! |
I'm sorry that I'm not able to upload an image as I'm still getting the error message mentioned earlier (although everything for github is whitelisted ...). You can see the image here: http://www.myimg.de/?img=js01b49.png |
Thank you very much, this allowed me to figure how to reproduce the bug. The key setting is that you have "Block third-party cookies and site data" enabled, while I don't. The fact that a 3rd-party cannot access the So this confirms extensions are also seen as 3rd-parties, which means they can't access a web site stored data if the setting is enabled, which I think is an interesting information (I will go enable mine). [Correction: content script executes as if origin is same as frame origin]. Also, this means that HTTPSB can't clear a site data (local storage) itself if the browser setting is enabled. [Correction: only for when inside frame, so actually feature still work properly.] I will work on a fix, for today hopefully. Regarding drag-n-drop of images on Github, I revised the preset rules, so you can whether update the 3rd-party assets for the new Github preset, or wait for the next release. A rule has to be created in the |
Raymond, I'm very glad that you found the "culprit". I temporarily allowed 3rd-party cookies and site data and loaded that website - and, hurray, the script cell for compass.pressekompass.net now shows 4 scripts. This confirms your findings. Thanks for your patience and persistence! |
http://www.spiegel.de/politik/deutschland/pressekompass-zum-afd-parteitag-bernd-lucke-unter-druck-a-960345.html
This site contains a frame from compass.pressekompass.net. If I whitelist the frame cell, nothing is shown and the related script cell remains empty. Once I whitelist the (empty) script cell for compass.pressekompass.net and reload the site, that cell now shows 3 scripts not shown before. A new line for kompassdemo.appspot.com appears and after whitelisting the script cell for the latter, the site is finally readable.
The text was updated successfully, but these errors were encountered: