430424 - [FIX]<object> mysteriously acquires type attribute (when plugin loads?)

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Jesse Ruderman]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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...

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Rip this code out

Comment 3

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/index.cgi/mozilla-central/rev/f7a0a6d4d496

Comment 4

[Boris Zbarsky [:bzbarsky]]

Jesse, can you think of a way to test this?