On 9/18/09 6:35 PM, Michael A. Puls II wrote:
With <object style="display: none" data="file.swf?vid=file.flv"> when
the page is parsed (or added to the document), what would happen?
Would it be something like this?:
1. Create the plug-in instance.
2. fetch file.swf
3. Give the file.swf stream to the plug-in when it requests it.
4. Fetch file.flv when the plug-in requests it
5. If autoplay, start playing the video (audio only since the <object>
isn't shown)
#5 is up to the plug-in; the browser doesn't do that part. What we
should do in this case, imo, is instantiate the plug-in, tell it the
data we have, tell it it's not being shown (has a null window in NPAPI
terms), and let it do whatever it wants with that situation. I believe
Flash, in theory, pauses itself whenever its window is set to null.
Or, would those optimizations not be triggered at all by display: none,
or would it depend on the plug-in or plug-in API or whatever the browser
feels like doing?
Depends on the plug-in and plug-in API, yes.
In other words, if browsers make it so display: none doesn't prevent the
loading of a plug-in, does display: none still prevent the automatic
streaming of the file in @data by the browser
I'd think no (especially since you have to do the data load to even
figure out whether the data is going to be handled by a plug-in to start
with; right now given the markup in your example Gecko will do the HTTP
GET on file.swf no matter what).
(for plug-ins, not native types like text/html)?
You don't know which it is until you've gotten at least the HTTP headers
of the response (and possibly the first 512 bytes of the body, or
whatever the content sniffing mechanism uses).
The reason I ask is that if existing web pages use multiple <object>'s
that load videos for example, that are initially set to display: none
and only shown later, then if browsers start fetching all these files as
soon as the page loads
They already have to do that, and will continue to, because the HTTP
headers from the response are needed to determine how to handle the
data. Right now they might just abort that load as soon as they
discover that the data is being handled by a plug-in. That's what Gecko
does. Note that aborting the load is sometimes a more expensive
operation (in terms of affecting the loading of other content) than
completing the load, depending on bandwidth, latency, and data size...
The higher the latency, the higher the bandwidth, and the smaller the
data, the more expensive canceling gets. Amusingly enough, that means
it's more expensive (holding data size constant) on your typical cell
phone than on your typical home PC...
-Boris
