Closed Bug 356095 Opened 18 years ago Closed 17 years ago

NPAPI GetProperty grabs garbage depending on <!DOCTYPE> statement in HTML

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: fleabix, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04324.17; InfoPath.2)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0

A plugin calling GetProperty through NPAPI will get different values depending on whether <!DOCTYPE is present in the HTML.  When the DOCTYPE is present, we get garbage, however, the call doesn't fail, it's still a success.

We're trying to grab the innerHTML from a set of <SCRIPT> tags, when the DOCTYPE is set, we get garbage, but if it's not there, we get the corrent contents of the tags.

The exact DOCTYPE tag is below:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Reproducible: Always

Actual Results:  
GetProperty suceeds and caller gets garbage.

Expected Results:  
GetProperty suceeds and caller gets good results.

Doesn't happen on IE.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Summary: PLUGIN: NPAPI GetProperty grabs garbage depending on <!DOCTYPE> statement in HTML → NPAPI GetProperty grabs garbage depending on <!DOCTYPE> statement in HTML
Version: unspecified → 1.8 Branch
Does this also happen with a nightly build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ ?
Still happens with the nightly build.
Latest nightly returns us error on the GetProperty when this DOCTYPE is set.
This bug also kills any Silverlight 1.0 applications/controls attempting to use inline XAML embedded on pages with the following DOCTYPE:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

This was verified in Firefox 2.0.0.7.
See the following link for more information regarding this bug and the inline XAML issue with Silverlight 1.0:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1146052&SiteID=1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Version: 1.8 Branch → Trunk
It appears that this bug kills the use of inline XAML for Silverlight 1.0 when ANY doctype is used, not just the XHTML 1.0 Transitional doctype that I previously listed above. Here are the doctypes I tried:

http://www.alistapart.com/stories/doctype/
Since 2.0.0.8 it appears the scope of the issue has spread. Earlier we could remove the DOCTYPE and have the contents of the <SCRIPT> tag available to the Silverlight plugin, but now it's a problem with/without DOCTYPE

Any workaround suggestions?
I have attached an HTML page that demonstrates the issue and how it impacts/prevents the use of inline XAML w/ Silverlight 1.0. Run in any version of Firefox greater than 2.0.0.7. If all is working correctly, all 4 Silverlight objects should display "Success!" as it does in IE/Safari. This now does not work in Firefox either with a DOCTYPE or without (which was a workaround before FF 2.0.0.8).

This issue is rapidly gaining importance as it impacts anyone who cannot use .xaml files with Silverlight because downloading a .xaml file is not always an option with cross-domain scenarios (e.g. advertising, or sharing/embedding Silverlight objects on a blog, MySpace, etc.)
Turns out that I was calling getting the element off of the NPWindow instead of calling GetElementById, which was what was causing the garbage.  When the call is made through GetElementById, it returned the correct values.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.