I'm creating a Chrome Web Extension, which uses the chrome.webRequest API to intercept and alter HTTPS requests.
Within their documentation, Google talk about different request types. One of these types is main_frame, which is a request for "a document that is loaded for a top-level frame".
To me this implies that Chrome treats everything as an iframe, but that doesn't seem right. What is the meaning of the "top-level frame" terminology?
The frame terminology is used to describe part of the Chrome browser's rendering process. Please see this article on Rendering Architecture for more information.
From the article, a frame contains:
DOM state,
CSS,
Canvases,
External resources, such as images, video, fonts, and SVG.
Therefore, a frame is a complete HTML document plus the document's URL.
It's actually correct to consider everything as an iframe, because that's how the Chrome browser views web pages when it's rendering them. The "top-level-frame" is the uppermost frame in a "frame hierarchy", and contains the information retrieved from the initial URL request. Any other frames, for example, iframes, are child frames of this "top-level-frame".
As an interesting aside, for performance purposes, frames from different websites are dealt with by different rendering processes. This is why your main web page (top-level-frame) can load quickly, whilst your iframe (child-frame) takes a few seconds.
Related
If you put video tags on a page, with not much other attributes other than src (just a onclick javascript handler), what is the usual behavior of browsers? Will they download the video(s) completely? Just some frames? Is this browser specific?
I have been asked to review a site, which showcases a lot of videos, so I am just curious.
This behaviour is browser specific and as browsers get updated so often it may change over time. I believe the spec 'advises' the default to be 'metadata' (see below).
There is a 'preload' attribute which can have several values to instruct the browser to do what you want. It is a 'hint' attribute so browser do not have to follow it:
auto - load when the page loads
metadata - only load the metadata when the page loads
none - don't load the video when the page loads
If the attribute is present with not value or an empty string then is taken as auto case above.
Its worth being aware that this page may be ignored in some cases - one common example was browsers on mobile devices which in the past generally ignored preload to protect a users data usage, although this is changing now.
More info here - worth checking as browsers change often: https://developer.mozilla.org/en/docs/Web/HTML/Element/video
Its probably worth mentioning also that if the video server is providing the video in a streamed format such as HLS or MPEG DASH, then the client will typically only download enough of the video to fills its buffer anyway. These protocols split the video into segments or chunks which the client downloads as required.
I'm curious to find out how a browser loads and renders a frameset. I know this may be different among different browsers. I am personally most concerned with how IE does it.
From my understanding, the browser will make one request for the page that contains the frameset. Upon rendering that page, the browser will then make a request for each individual frame's content within that frameset.
Is this correct and if so, are the requests for individual frames within the frameset done asynchronously or are the requests performed linear?
This is assuming that we are purely using HTML.
From my understanding, the browser will make one request for the page that contains the frameset. Upon rendering that page, the browser will then make a request for each individual frame's content within that frameset.
Yes, that's basically correct.
are the requests for individual frames within the frameset done asynchronously or are the requests performed linear?
From memory (and I haven't worked with Framesets in a loooong time), it is asynchronous.
Framesets are basically an obsolete technology, and haven't really been in common use for a long time now, but I'd be very surprised if it works any differently to iframes, which are asynch.
You specifically asked about IE. For current IE versions, there really shouldn't be any major differences between IE and the other browsers.
But older IE versions (IE8 and earlier) had quite tight restrictions on the number of files they were capable of loading asynchronously. If I recally correctly, the limit was just two files at a time, or something of that order.
Given that, if you've got more than a couple of files in your frameset and you load it in an old IE version, then the answer is yes, it probably will load at least some of them linearly.
But the best advice really is to avoid framesets entirely. They are deprecated for good reasons.
Firefox 25 says to bring Web Audio but an important functions seems to be missing - createJavaScriptNode.
I'm trying to build a analyser but I get the error in console that createJavaScriptNode is not a function.
Demo - http://jsbin.com/olugOri/3/edit
You can try using createScriptProcessor instead. Firefox is still not getting correct values, but at least that error is no longer present.
Demo - http://jsbin.com/olugOri/4/edit
Edit: (more visibility for the important discussion in the comments)
Firefox does support MediaElementSource if the media adheres to the Same-Origin Policy, however there is no error produced by Firefox when attempting to use media from a remote origin.
The specification is not really specific about it (pun intended), but I've been told that this is an intended behavior, and the issue is actually with Chrome… It's the Blink implementations (Chrome, Opera) that need to be updated to require CORS.
MediaElementSource Node and Cross-Origin Media Resources:
From: Robert O'Callahan <robert#ocallahan.org>
Date: Tue, 23 Jul 2013 16:30:00 +1200
To: "public-audio#w3.org" <public-audio#w3.org>
HTML media elements can play media resources from any origin. When an
element plays a media resource from an origin different from the page's
origin, we must prevent page script from being able to read the contents of
the media (e.g. extract video frames or audio samples). In particular we
should prevent ScriptProcessorNodes from getting access to the media's
audio samples. We should also information about samples leaking in other
ways (e.g. timing channel attacks). Currently the Web Audio spec says
nothing about this.
I think we should solve this by preventing any non-same-origin data from
entering Web Audio. That will minimize the attack surface and the impact on
Web Audio.
My proposal is to make MediaElementAudioSourceNode convert data coming from
a non-same origin stream to silence.
If this proposal makes it into spec it will be nearly impossible for a developer to even realize why his MediaElementSource is not working. As it stands right now, calling createMediaElementSource() on an <audio> element in Firefox 26 actually stops the <audio> controls from working at all and throws no errors.
What dangerous things can you do with the audio/video data from a remote origin? The general idea is that without applying the Same-Origin Policy to a MediaElementSource node, some malicious javascript could access media that only the user should have access to (session, vpn, local server, network drives) and send its contents—or some representation of it—to an attacker.
The HTML5 media elements don't have these restrictions by default. You can include remote media across all browsers by using the <audio>, <img>, or <video> elements. It's only when you want to manipulate or extract the data from these remote resources that the Same-Origin Policy comes into play.
[It's] for the same reason that you cannot dump image data cross-origin via <canvas>: media may contain sensitive information and therefore allowing rogue sites to dump and re-route content is a security issue. - #nmaier
I keep hearing all about HTML5 and how great it is, but if I don't really care about audio and video, is there anything it really changes for me? I've read up on the new tags it supports and they just don't seem to be all that revolutionary beyond its video and audio capabilities.
Shamelessly copy-pasted from wikipedia:
The canvas element for immediate mode 2D drawing.
Timed media playback (possibly not interesting for you)
Offline storage database (offline web applications). See Web Storage[21]
Document editing (via DOM API and user interface)
Drag-and-drop
Cross-document messaging
Browser history management
MIME type and protocol handler registration.
Microdata
Browser-based SQL databases
Oh, and WebSockets to replace AJAX and Comet.
http://en.wikipedia.org/wiki/HTML5#New_APIs
DOM storage
Canvas
Drag'n'drop
Semantic microformats support
One of the biggest deals about HTML5 which is under reported is that HTML4 never defined error handing, but this is well defined in HTML5. All browser vendors are building HTML5 parsers that conform to this spec. While this is not sexy, the end result will be that browsers will become more interoperable with each other (especially in cases where the author makes an error). In the long run this should mean you'll spend less time trying to get all browsers to work correctly, and users will benefit from less broken sites in their browser of choice.
HTML5 also allows you to make more application quality sites, using many of the technologies mentioned in the other answers. Opera Dragonfly (the project I'm involved with) is a complex web app which doesn't use audio or video but takes advantage of a large number of HTML5 technologies. We use AppCache to make sure it still works when you are offline, Web Storage to save user preferences and history (we can store a lot more information than cookies allowed) and will likely use Web Workers to allow the app to use more than one process at once (will speed up performance on mult-core machines).
If you are doing anything with graphics then the Canvas API gives you a lot of drawing options, while SVG (an open vector format) can be used within your HTML pages now. Previously pages had to be served as XML for SVG to be included inside them.
In a web-based system I maintain at work that recently went live, it makes an Object element to embed a second web page within the main web page. (Effectively the main web page contains the menu and header, and the main application pages are in the object)
For example
<object id="contentarea" standby="loading data, please wait..."
title="loading data, please wait..." width="100%" height="53%"
type="text/html" data="MainPage.aspx"></object>
Older versions of this application use an IFRAME to do this though. I have found that by using the object tag the embedded web page behaves differently to when it was previously hosted in an IFRAME. In IE, for example, the tool tips don't seen to work (I will post a separate question about this!), and it looks like the embedded page cannot access the parent page in script, although it can if it was an IFRAME.
I am told the reason for favouring the object tag over the IFRAME is that the IFRAME is being deprecated and so cannot be relied on for future versions of browsers. Is this true though? Is it preferable to use the Object tag over the Iframe to embed web pages? Or is it likely that the IFRAME will be well-supported into the future (long after I am old and grey, and past the useful life of the application I maintain)?
The IFRAME element is part of the upcoming HTML5 standard. Also, HTML5 is developed by the major browser vendors out there (Mozilla, Opera, Safari, IE), that basically makes a guarantee that we will have an IFRAME element in the foreseeable future. Some of them have support for some HTML5 elements already, like AUDIO and VIDEO and some new JavaScript APIs.
It's also true that the OBJECT element is in the draft, but that's because IFRAME and OBJECT will have different purposes. IFRAMES are mainly designed for sandboxing web applications.
So, my advise is to use IFRAME instead of OBJECT.
If you are embedding a HTML page, here is one noticeable difference between iframe and object:
with iframe updating src will change the browser history (adding a new entry)
with object updating data will not change the browser history
Also it seems like drag&drop does not work if the page is embedded in the object tag, but works in the iframe tag. I noticed it personally using react-draggable, and I can see someone had the same issue (https://stackoverflow.com/questions/31807848/replacing-iframe-with-object-tag-drag-and-drop-not-working)
IFRAMEs are not part of the XHTML 1.0 Strict DTD. They are totally valid in in HTML 4 and XHTML 1.0 Transitional, I believe. For these reasons alone, IFRAME will continue to be supported for a long time.
A lot of bookmarklets and analytics code still use IFRAMEs.
Although the W3C specs may indicate that the IFRAME tag is being deprecated, (in XHTML at least anyway), browser developers do not necessarily follow exactly what those specs say (IE6 anyone?)
As use of IFRAMEs is so prevalent at the moment, and the W3C can't seem to decide if they are part of the future or not (HTML 4.01 vs XHTML), I am pretty sure they are the safer implementation to use for almost every browser.