In manifest.json, we specify our background page and can put an html or a js file for it. Since it is only a script that executes what sense does it make to have an html file for it?
I mean where is UI going to get shown anyway?
Similarly the devtools_page property has to be an html file. What sense does that make?
It will not be shown anywhere (that's the essence of "background"), but some elements on it make sense.
You can have an <audio> tag, and if you play it, it will be heard.
You can have an <iframe> with some other page loaded invisibly.
..and so on
As for devtools_page, it would actually be visible in the interface (as an extra panel in the DevTools)
It is possible that devtools_page must be an HTML file just for legacy reasons: it was not updated when manifest version 2 rolled out with changes to how background pages are specified. Still, the same arguments as above apply.
background_page is a legacy feature from the initial support of extensions in Chrome. background.scripts was added in Chrome 18. I can't speak for Google's original intentions but I'd guess that in the original design using an page felt more natural and would be less likely to confuse developers. Once they realized how many background_pages were just being used to load JavaScript it made sense to explicitly support that.
Related
On my TYPO3 v10 website I have some SVG icons in use, no problem.
I also have a few more complex SVG Figures (created with Inkscape), that I want to include in TYPO3 website. Of course I can upload the .svg files to the fileadmin/ folder, and link to them with the Text+Image (or Text+Media) Content Elements.
In the Backend, TYPO3 generates some fine png-thumbnails for preview. So far so good.
The file can be downloaded directly, from its fileadmin/images ... location.
However, inside web pages, my SVGs are not displayed as they should.
A lot of styling information gets removed from the SVG and I don't know where.
Here is a screenshot of the original vs corrupted image (as displayed in the TYPO3 frontend).
Here is a graphical diff that shows the difference between the figures.
It turns out that at some time during the rendering process, TYPO3 removes the values from the style="...." SVG attributes. See reddish boxes.
All my more complex SVGs look like the one on the right when embedded in TYPO3.
Here is the SVG if you want to try yourself: image on SVGshare.com
On the right, many style attributes have been set to style="".
but why?
It's Firefox, not TYPO3, who removes the style="..." attribute values. This seems to be a longstanding Firefox Issue, solved.
See Bugzilla Issue 1262842: [CSP] Blocks the use of style attributes inside SVG without generating console errors.
Look for "triply confusing" in the first comment.
Inline CSS styles can be a security Problem, and therefore Firefox has a Content-Security-Policy (CSP) in place, in order to correct this.
An explainer for the mitigation strategies, written jointly by professional Security Engineers is given in this Google Doc and in Gihub Repo (Content Security Policy), Issue 45, Further granularity of unsafe-inline styles.
Script inline attributes are a difficult subject to approach when it
comes to CSP, they have the same amount of power as any other script
element but they don’t have ways to be whitelisted, for example, by a
nonce or hash. This means that the actual content of the attribute is
mostly the only deciding factor.
I don't understand everything mentioned in these docs and discussions. Inline-style Elements seem to be vulnerable to XSS attacks, and then attacker can put CSS url() in there for instance.
Quick-and-dirty solution
Use Inkscape and save as "optimized SVG", and check the option "Convert CSS Attributes to XML attributes". See attached screenshot of the Inkscape Dialog (Linux).
This solution was proposed by a web-developer from the GIMP devteam.
TYPO3 9 introduced an SVG Sanitizer, which automatically modifies SVG files during "fileadmin upload time", meaning it removes any <style ...> elements from the uploaded SVG file.
In TYPO3 10 and later versions, this SVG Sanitizer is by default automatically set up via Symfony dependency injection via core's Services.yaml.
You can remove the SVG Sanitizer via your own site extension's Services.yaml, e.g. for your myextension/Configuration/Services.yaml:
services:
_defaults:
autowire: true
autoconfigure: true
public: false
# ...
# remove TYPO3's default-autowired SvgSanitizer, which tampers with filadmin uploaded SVGs (e.g. removes necessary <style> information)'
TYPO3\CMS\Core\Resource\Security\SvgEventListener: ~
The tilde (~) removes/overwrites the definition previously set up by core's Services.yaml ( https://symfony.com/doc/current/service_container/service_decoration.html ).
This seems to be a problem of your individual TYPO3 installation. I've just tested your SVG image in a brand new TYPO3 v10 installation and the image is rendered properly in backend and frontend.
Maybe you have some 3rd party extensions installed who postprocess the HTML output of TYPO3, e.g EXT:sourceopt or EXT:scriptmerger.
I understand that the background page of a Chrome extension is never displayed. It makes sense to me that a background page should contain only scripts. In what situations would HTML markup ever be needed?
At https://developer.chrome.com/extensions/background_pages there is an example with an HTML background page, but I haven't been able to get it to work (perhaps because I am not sure what it should be doing).
Are there any examples of simple Chrome extensions which demonstrate how HTML markup can be useful in a background page?
Historical reasons
The background page is, technically, a whole separate document - except it's not rendered in an actual tab.
For simplicity's sake, perhaps, extensions started with requiring a full HTML page for the background page through the background_page manifest property. That was the only form.
But, as evidenced by your question, most of the time it's not clear what the page can actually be used for except for holding scripts. That made the entire thing being just a piece of boilerplate.
That's why when Chrome introduced "manifest_version": 2 in 2012 as a big facelift to extensions, they added an alternative format, background.scripts array. This will offload the boilerplate to Chrome, which will then create a background page document for you, succinctly called _generated_background_page.html.
Today, this is a preferred method, though background.page is still available.
Practical reasons
With all the above said, you still sometimes want to have actual elements in your background page's document.
<script> for dynamically adding scripts to the background page (as long as they conform to extension CSP).
Among other things, since you can't include external scripts through background.scripts array, you need to create a <script> element for those you whitelist for the purpose.
<canvas> for preparing image data for use elsewhere, for example in Browser Action icons.
<audio> for producing sounds.
<textarea> for (old-school) working with clipboard (don't actually do this).
<iframe> for embedding an external page into the background page, which can sometimes help extracting dynamic data.
..possibly more.
It's debatable which boilerplate is "better": creating the elements in advance as a document, or using document.createElement and its friends as needed.
In any case, a background page is always a page, whether provided by you or autogenerated by Chrome. You can use all the DOM functions you want.
My two cents:
Take Google Mail Checker as an example, it declares a canvas in background.html
<canvas id="canvas" width="19" height="19">
Then it could manipulate the canvas in background.js and call chrome.browserAction.setIcon({imageData: canvasContext.getImageData(...)}) to change the browser action icon.
I know we could dynamically create canvas via background.js, however when doing something involving DOM element, using html directly seems easier.
I have a big SVG document here, containing a map of all the quests in a certain online game. Each quest node is inside a SVG <a> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest. This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad. It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.
This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now. The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.
Further details:
I've tried doing the named anchors in both the old <a name="..."> form, and the newer <h1 id="..."> form. No difference.
I've tried adding an onhashchange handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).
I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once. (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)
Anybody have an idea for a work-around?
Are Content Scripts (http://code.google.com/chrome/extensions/content_scripts.html) injected into prerendered pages (document.webkitVisibilityState== 'prerender') ?
I’ve been reading https://developers.google.com/chrome/whitepapers/prerender and https://developers.google.com/chrome/whitepapers/pagevisibility, and am trying to figure out how Content Scripts work with page prerendering/prefetching.
Thanks
TheZ, tomdemuyt: I’m afraid you guys are missing the point. ‘run_at’ specifies whether the content script is injected before or after the DOM is constructed.
However, I am talking about document.webkitVisibilityState, which can be ‘prerender’ (when the page is in a background/invisible tab), ‘hidden’, or ‘visible’. Note that webkitVisibilityState can transition from ‘prerender’ to ‘hidden’ or ‘visible’, or back and forth between ‘hidden’ and ‘visible’, without any changes being made to the DOM. (In order to better understand this, read the articles linked in my original post.)
I think I’ve been able to determine that content scripts ARE injected into prerendered pages. Here’s the problem, however: let’s say my content script does something that should not occur on a prerendered page. For instance, it does pageview count, or adds animation, neither of which should begin until the user is actually viewing the page. So it seems that my content script should do something like what’s shown in the code examples on https://developers.google.com/chrome/whitepapers/pagevisibility - check document.webkitVisibilityState, and also listen to the ‘webkitvisibilitychange’ event, and only do pageview count/start the animation when document.webkitVisibilityState is, or has transitioned to, ‘visible’.
I may have just answered my own question, but I just wanted to make sure that I was on the right track.
Thanks
As TheZ mentioned, you should ues the run_at setting.
Link to docs : http://code.google.com/chrome/extensions/content_scripts.html#registration
I am writing a Google Chrome extension. The targeted pages are written in Russian. Chrome translates to English. I can see some inconsistencies appear that seem to be linked to translation. For example, in the following code I check to see if I am in a particular folder:
if (searchResult[0].innerHTML.indexOf("Общая папка")!=-1) alert("You are in Shared Folder."); else (alert(searchResult[0].innerHTML));
If I reload the exact same page several times, the result is inconsistent. Sometimes it detects "Общая папка" but other times it does not. When it does not detect this phrase, the alert says I am in "Shared Folder" which is the translation for ""Общая папка." There appears to be no consistency here. Sometimes I am dealing with the original text (which is preferred) but sometimes I am dealing with crappy translations that are useless for my script because the translations change all the time.
Does anyone know how to fix this? Turning it off would probably fix it but actually the translations are useful and necessary for other aspects of the extension. I understand that the translation works with some secondary layer of the HTML (I have not researched this very well). Can I simply refer to the original in my script?
According to this answer, you can disable translation by placing the following element in the head portion of your web page:
Insert this to the head section of your web page.
<meta name="google" value="notranslate">
If you needed to programmatically disable translation, you could add that tag through JavaScript.
Not sure about disabling it, but looks like after a translation Chrome adds class="translated-ltr" to <html> element, so maybe you at least can detect when the page was translated and either warn a user that the extension might not work properly on this page or just disable it.