Steps to reproduce: 1. Load http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cbody%3E%3Cobject%20data%3Dflash%3E 2. Add a space. Result: The object element is shown as having an attribute type="application/x-shockwave-flash" Expected: The object should continue to not have a type attribute.
Gah. It looks like bug 277434 only sort of got fixed. nsPluginStreamListenerPeer::OnStartRequest still calls SetType(), not SetActualType(), which is what's setting the attribute now... Not that anyone _uses_ the thing it sets. Which means this stuff was likely "broken" in 1.8 (writing to .type, reading .actualType), and no one ever noticed. That argues that it's not so useful, to me. In any case, now that we have nsObjectLoadingContent, which implements an actualType getter that has nothing to do with attributes, can we just rip out the nsPluginStreamListenerPeer::OnStartRequest code? It would be good to not mess up the DOM like this...
OS: Mac OS X → All
Hardware: PC → All
Created attachment 329565 [details] [diff] [review] Rip this code out
10 years ago
Summary: <object> mysteriously acquires type attribute (when plugin loads?) → [FIX]<object> mysteriously acquires type attribute (when plugin loads?)
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Jesse, can you think of a way to test this?
You need to log in before you can comment on or make changes to this bug.