createLSParser not supported but hasFeature is reporting that the LS interface is implemented.

NEW
Unassigned

Status

()

defect
P5
normal
7 years ago
5 months ago

People

(Reporter: MLTGuzzi, Unassigned)

Tracking

({regression})

19 Branch
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E; MS-RTC LM 8; AskTbORJ/5.14.1.20007)

Steps to reproduce:

Determine browser capability by checking;
   document.implementation.hasFeature('LS', '3.0')
it returns true, but document.implementation.createLSParser is undefined.


Actual results:

We are using SoftXMLLib.js for cross browser XML handling.  It uses the check above to determine if LS is available, then fails when it calls createLSParser.  I have added a direct check for document.implementation.createLSParser as a workaround, but others may experience this problem.


Expected results:

Either createLSParser should work, or document.implementation.hasFeature('LS', '3.0') should return false.
Component: Untriaged → DOM
Product: Firefox → Core
(In reply to Martin Turner from comment #0)
>  I have added a direct check for
> document.implementation.createLSParser as a workaround
Note, that is the normal way to check whether a browser supports some feature; check if the relevant function is there.
Blocks: 801425
Martin, see what the dom4 spec says at http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature 

Basically, hasFeature is deprecated at this point...  Anne, note the web compat problem here; perhaps the 'LS' feature should always return false since no one actually implements DOM3 LS?
Flags: needinfo?(annevk)
1) Is there any browser code out there that does support createLSParser? This seems like a really strange thing to check for.

2) Of course we can do that... My initial plan was to create a fixed list, but (iirc) Aryeh came up with this solution. Adding an exception just for LS seems weird.
Flags: needinfo?(annevk)
I see that the V4 spec calls for hasFeature to return true.  That seems strange, considering that the features of LS are not present.  Yes we have it, but it isn't there.

The SoftXMLLib.js library we are using is older, from around 2006 I think, and it uses hasFeature.  I see your point about checking the feature directly, and I've modified the library to handle it.  It worked fine up until we migrated from Firefox 16 to Firefox 19.  So, either createLSParser was removed or the return from hasFeature('LS', '3.0) must have changed between those two versions of Firefox.
(In reply to Martin Turner from comment #4)
> It worked fine up
> until we migrated from Firefox 16 to Firefox 19.  So, either createLSParser
> was removed or the return from hasFeature('LS', '3.0) must have changed
> between those two versions of Firefox.

Yes, check bug 801425 that landed in FF19.
> Is there any browser code out there that does support createLSParser?

Not that I know of.  The library in question seems to have been largely written 7+ years ago (based on http://www.softxml.com/softxmllib/ and comment 4), when people thought DOM L&S would go somewhere maybe, I guess, and wanted to be future-compatible?

The question is whether this library is deployed widely enough that this is a compat issue we need to deal with no matter how weird the result is.
(In reply to Anne (:annevk) from comment #3)
> 1) Is there any browser code out there that does support createLSParser?
> This seems like a really strange thing to check for.

Presto Age of Opera :)
I can confirm: "document.implementation.createLSParser is not a function" happens and is a problem for some existing programs.  Moreover, this is a Firefox REGRESSION (failure to provide backward compatibility) BECAUSE IT USED TO WORK (for years).  Example of what used to work and now does not because Backwards Compatibility is apparently insufficiently a concern of FF (Mozilla) developers:  http://mynichecomputing.org/NewsTicker/slow.htm  (I have myself experienced 3 other cases of FF failing to provide backward compatibility OR failure to provide even some basics, if new features are used.)
> BECAUSE IT USED TO WORK

Er...  createLSParser never worked, in case that wasn't clear.
Well, at the very least it did not cause a problem and let OTHER THINGS WORK. Now (at the very least), the (In reply to Boris Zbarsky (:bz) from comment #9)
> > BECAUSE IT USED TO WORK

Er...  createLSParser never worked, in case that wasn't clear.
Well, at the very least it did not cause a problem and let OTHER THINGS WORK. Now (at the very least), the

"TypeError: document.implementation.createLSParser is not a function"

causes things to NOT work. Again (and please do not treat me like a horror movie 
character), the program at http://mynichecomputing.org/NewsTicker/slow.htm  
worked for YEARS in Firefox until the more recent versions

(In reply to Boris Zbarsky (:bz) from comment #9)
> > BECAUSE IT USED TO WORK

Er...  createLSParser never worked, in case that wasn't clear.
http://mynichecomputing.org/NewsTicker/slow.htm  which 'uses' createLSParser 
does presently work in IE (and did work for several year, or at least did not not work, in Firefox for several years)

(In reply to Anne (:annevk) from comment #3)
> 1) Is there any browser code out there that does support createLSParser?
> This seems like a really strange thing to check for.

2) Of course we can do
> that... My initial plan was to create a fixed list, but (iirc) Aryeh came up
> with this solution. Adding an exception just for LS seems weird.
OK, I think we should revisit this hasFeature situation, if sites are actually using it.  :(
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(annevk)
Keywords: regression
http://wiki.whatwg.org/wiki/DOM_features was the work in progress before it was made to mostly return true.

I can take that list, remove those that are new, such as TextEvents and Selectors-API, add the SVG URLs, and return true for that set, ignoring the version number argument. Would that work?
Flags: needinfo?(annevk)
I have to admit it's pretty tempting to me to just return false for the LS feature and keep doing true for everything else...  not sure how others would feel about that, though.
Special casing LS and SVG works too, but we might unknowingly have broken more than just LS. (We should consider removing the SVG special casing long term.)
NOTE: I took actions to make http://mynichecomputing.org/NewsTicker/slow.htm work in both the new Firefox and in IE.  THUS: The fact that this page shows no problem has nothing to do with problems you may be still creating by generating fatal "TypeError: document.implementation.createLSParser is not a function" errors. I simply did work arounds and used the Firefox new xml parser system. Creating fatal errors of the type, "TypeError: document.implementation.createLSParser is not a function" would most definitely  be problems for those not making workarounds.  I left old version of the relevant js files (FOR YOU) at: http://mynichecomputing.org/NewsTicker/js/oldxparser.js and http://mynichecomputing.org/NewsTicker/js/oldzxml.js so you can still see the code that does NOT work (and may be similar to others old code -- the basic code came from Nicholas C. Zakas so IT IS NOT BAD CODE;  Others may surely still rely on such code running).
P.S. To see my new js files, see the same addresses, except without the prefix 'old' in front of the names.  I would be happy for input if I made my workarounds too limited, so (for example) the code only works in IE and FF. Perhaps a kind soul would give me input.
>                //Create the parser in synchronous mode.
>               if(!document.all) {

Why don't you just use |if(document.implementation.createLSParser) {|? This is the recommended method.
(In reply to Anne (:annevk) from comment #3)
> 1) Is there any browser code out there that does support createLSParser?

Sure, Presto's DOM implementation has supported DOM3 LS for years. It pre-dates XHR (and indeed the first XHR implementation was just a wrapper on top of DOM3 LS).

We didn't do it exactly like Gecko though.. So oldzxml.js contains for example this:

		    //sorry opera, 
		    if (!window.opera) {
				    //mozilla-specific way of handling errors
            oDomDocument.prototype.__checkForErrors__ = function (oEx) {
        
                if (this.documentElement.tagName == "parsererror") {

That's perhaps another piece of evidence that indicates hasFeature('LS') should return false - unless you also want to keep that really weird <parsererror> document stuff..
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.