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)
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.
Updated•18 years ago
|
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
Comment 1•18 years ago
|
||
Does this also happen with a nightly build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ ?
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/
Comment 7•17 years ago
|
||
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.)
Attachment #285938 -
Attachment is obsolete: true
Reporter | ||
Comment 10•17 years ago
|
||
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
Flags: tracking1.9?
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•