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
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.
I want to create my webpage so that a part at the top that says "Welcome!" and a "main part" below that. When a user clicks on a link in the main part (say, it links to www.example.com), the main part should change to the content of www.example.com, but the top part should remain the same. How can I achieve that?
In ye olde days, this was done using frames, but for many reasons, they are going out of use. Try taking a look at iframes.
I believe you're looking for the
<frameset>
tag: http://www.w3schools.com/tags/tag_frameset.asp
The <frameset> tag is not supported in HTML5. Although <iframe> works, it will impact your page's searchability (SEO), and setting up the page to scroll properly will be a hassle because the "top" part of the page will be like a page of itself.
Instead of using (i)frames, if you have PHP enabled on the server, you should store the "top" of your webpage as a separate file like "top.php", and in every page, include that with
include_once("top.php")
Suppose I want the browser to load an image right on the first connection it makes to my website. How do I do that, considering that by default the image loads later on when it's actually called for?
Also, after the whole page finishes loading, suppose I want to load more objects (say images) that aren't required yet but are just for buffer. How do I do that? Help me people, I've been at it for quite a long time.
I'm somewhat successful with the first problem by adding a script tag while actually calling an image at the beginning of my index.php's html head part which goes like:
<script src="http://www.mysite.com/my/image/url.png"></script>
But this I realize is bad scripting.
As for "Why would you want to do that?", it's for educational purposes and also because when someone visits my site, I need to load and display certain things before other things get loaded.
For preloading you probably could start with
<body onLoad="Preload('image1.jpg', 'image.gif', 'image.png', ...)">
And preload is a JavaScript function which adds each of the array of images to DOM like
document.imageArray[i].src = args[i];
At the top of many pages in our web application we have error messages and notifications, 'Save' and other buttons, and then our h1 tag with the content title. When making a web application accessible, is it ever acceptable to have content above the top-level structure tag like we do here?
As a screen reader user I don't like content above the main heading. Normally I navigate by headings so would miss the error message. A better solution is to output an h1 heading above the error message, then leave the rest of your headings in tact giving you two h1 headings.
Yes (you can put stuff above them). The H simply means Heading. It's a question of what the heading relates to I guess.
My only caveat is, H2 shouldn't really be above H1, and H3 Shouldn't be above H2. But I don't think it's an actual rule.Websites have menus, warning, notifications. It's acceptable to put them above the rest of your content. I don't see how it would affect accessibility as long as your content is ordered logically. Look at the page CSS turned off. Does it look logical? That's the most important part of accessibility.
Although some people do go that extra mile and have the menu as the last item in the markup and use CSS to bring it back to the top. Personally, I find that solution counter productive. The menu is still important, it belongs at the top of the page.
Yes, just consider it is in that order that the user will get the information. So, if you just did an operation it sounds like a good idea to get any message related to it as the first thing. If it is a notification that appears on any page unrelated to what you are doing, I wouldn't put it above, as it might be a little weird.
Also you can use a text browser that doesn't use styles, it should look like a document with appropriate headers.
Heading tags are used to indicate the hierarchy of the content below it. You should only have one h1 tag and it should be the first content to appear on your page (this is usually the name of the site). Also, you shouldn't skip heading tags when drilling down through different tiers of content.
In your case, you can still use CSS to position items above the h1 tag as long as it is in the correct order in the html.
I assume the elements above the heading are used by JavaScript. In that case, it's preferable if they are created by JavaScript, not included in the source of the page.
To return to your original question, it is probably best that they be at the foot of the page. However, if they are hidden using the CSS "display: none;" or "visibility: hidden;" properties then they will not be seen by most (perhaps all?) screenreaders or by many other assistive technologies, and so should not be an issue. I've written a fairly detailed explanation of why accessibility technology ignores such elements.
Of course if somebody disables CSS things are going to look pretty messy. If there is content on the page that can be used even when CSS and/or JavaScript are disabled, then putting those elements at the bottom of the page will at least make things less cluttered.