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.
Related
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.
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.
Question: Is there a easy way to detect the browser of the user ?
Details: I would like to change for example the value of background-color of body. I've already see something like <!--[if !IE]>.
Edit:
Okay, I agree, browser detect is bad (Link taken from #TylerH), and should not be used. Thank I take note. And If someone really still want to use them, I've found a good website with a list of browser detection hack.
I think there is no way to do it with HTML or CSS (I don't like hacks).
But you could check the user agent string with JS.
See here: How to make CSS visible only for Opera
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