This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Due to the way <object> loads work, the browsing context is not created until the server response has been received. This can lead to unexpected behavior for some things that tests may want to test. It would be better to run the tests in an iframe instead.
Boris, can you give an example of "unexpected behavior"?
Well, for example the Navigation Timing APIs behave somewhat differently in an <object> and an <iframe>, because in the former case the object that should record the load start time doesn't exist at load start. At least in Gecko. Per spec it's not obvious to me what the <object> behavior should be.
I believe that the mobile folks are also interested in using an iframe instead of an object, btw.
IIRC the code used an iframe but was changed to an object before I took over. I'm trying to find out what the reason was for the change back then. If there are some tests that need an object then this will have to be a configurable option... if so, I'm trying to determine if it needs to be per test or per suite.
Tests that want an object can put an <object> in their test, right?
(In reply to comment #3) > I believe that the mobile folks are also interested in using an iframe instead > of an object, btw. Yes, I think I remember Francois saying that you can't scroll in the object area when you are using the system from a mobile browser.
I confirm. Actually, whether an <object> or an <iframe> gets used doesn't make a difference in terms of scrolling in typical mobile browsers on touchscreens: they don't allow users to scroll embedded contents. Scrolling only works for the whole page. The difference between <object> and <iframe> is that these mobile browsers will automatically adjust the size of an <iframe> to fit that of the content it contains. They won't do so with <object> meaning that, no matter what value of "overflow" you may set, the embedded content is likely to appear truncated on mobile browsers. I don't think there is any drawback in using an <iframe> instead of an <object> to embed content.
Taking this bug. I have a number of page style improvements from the Shepherd project that I'm going to back-port into the test framework, among which include a fix for scrolling behavior on mobiles. I'll do the object/iframe switch as part of that work.
This is now fixed in the release that's now online. In the running interface, there's a checkbox for "use iframe" which switches the test runner from object to iframe. That preference sticks in a cookie so that once you've used it your choice will stick for the same browser/device combo, which is probably the behaviour you want. You can see an example at http://w3c-test.org/framework/app/suite/css-selectors-api-1-baseline/run/full/most-needed/1/level1-additional.html