bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

hasFeatures not showing support for CSS, CSS2 and Events

RESOLVED FIXED in mozilla1.3final



DOM: Core & HTML
18 years ago
7 years ago


(Reporter: martin, Unassigned)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: trivial fix [ADT3])


(3 attachments, 1 obsolete attachment)



18 years ago
<script language="JavaScript"><!--
features = new Array('HTML', 'Views', 'StyleSheets', 'CSS' ,'CSS2', 'Events',
'UIEvents', 'MouseEvents', 'MutationEvents', 'HTMLEvents', 'Traversal', 'Range');

output = '';
for (var i in features)
    output += features[i] + ' - ' +
document.implementation.hasFeature(features[i],'1.0') + '\n';

Which shows:

HTML - true
Views - false
StyleSheets - false
CSS - false
CSS2 - false
Events - false
UIEvents - false
MouseEvents - false
MutationEvents - false
HTMLEvents - false
Traversal - false
Range - false

Although I beleive that DOM2 Events is only 80% surely it should be supporeted
in hasFeatures()?
Confirming using 20000511, upping severity. I'll attach the file.

vidur - could you have a glance at this?

Severity: normal → major
Ever confirmed: true
Created attachment 8571 [details]
JS in comment as a .html
Nominating nsbeta2. The whole point of hasFeatures is to provide a way for 
JavaScript code to determine what functionality is available. It would be nice 
if we returned accurate information for FCS. ;->
Keywords: nsbeta2
This one's mine.

I update hasFeature() some time ago, currently we report that we support

  XML (DOM versions 1.0 and 2.0)
  HTML (DOM versions 1.0 and 2.0)
  Views (DOM versions 2.0)
  StyleSheets (DOM versions 2.0)
  CSS (DOM versions 2.0)
  CSS2 (DOM versions 2.0)
  Events (DOM versions 2.0)
  UIEvents (DOM versions 2.0)
  MouseEvents (DOM versions 2.0)
  HTMLEvents (DOM versions 2.0)
  Range (DOM versions 2.0)

but according to joki we should not say we support UIEvents, so that needs
to be removed.
Assignee: vidur → jst

Comment 5

18 years ago
spoke with ekrock - Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
We should make this change for beta3 tho, we don't wanto give false info to the
callers of hasFeatures(), and the risk in this change is practically
Keywords: nsbeta3
OS: Linux → All
Priority: P3 → P2
Hardware: PC → All
Target Milestone: --- → M18

Comment 7

18 years ago
Marking nsbeta3+...
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]


18 years ago
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3+] trivial fix


18 years ago
Last Resolved: 18 years ago
Resolution: --- → FIXED
Component: DOM Level 2 → DOM Style
Taking QA Contact on all open or unverified DOM Style bugs...
QA Contact: vidur → ian
Component: DOM Style → DOM Core
QA Contact: ian → stummala

Comment 10

17 years ago
still shows 
HTML - true
Views - false
StyleSheets - false
CSS - false
CSS2 - false
Events - false
UIEvents - false
MouseEvents - false
MutationEvents - false
HTMLEvents - false
Traversal - false
Range - false

reopening the bug
Resolution: FIXED → ---

Comment 11

17 years ago
The reason it shows all these false is because hasFeature() is called with the
1.0 version. However all of those modules are defined in the 2.0 version only.
Should we close this bug again?
IMHO the hasFeature() bugs have been around for too long (bug 62673, bug 63345)
and we should decide at some point.
Summary: Currently the situation is as follows
XML and HTML 1.0 and 2.0 : true.
Core 2.0 : false
Views 2.0 : true
StyleSheets 2.0 : true
CSS 2.0 : true
CSS2 2.0 : true
Events 2.0 : true
UIEvents 2.0 : false
MouseEvents 2.0 : true
MutationEvents 2.0 : false
HTMLEvents 2.0 : true
Range 2.0 : true
Traversal 2.0 : false
I suggest the following changes, based on the two other bugs cited above.
Core 2.0 -> true
CSS 2.0 -> false
CSS2 2.0 -> false

Any thought? Should I add David Flanagan to the CC list (since he filed bugs
about hasFeature())?
Adding Ian because he has reacted about hasFeature() in the other bugs and
probably knows better what we support and what we don't.

Comment 12

17 years ago
Er forgive me for this little mistake:
CSS2 2.0 returns false and not true.
The change suggested for CSS2 2.0 is thus not necessary.
resolving worksforme.  We report "true" for the things we actually support (and
possibly some we do not support completely, but those are separate bugs).
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 14

17 years ago
reopening bug. I used hasfeature() with version 2.0 and css2 returned false.
attaching testcase.
Resolution: WORKSFORME → ---

Comment 15

17 years ago
Created attachment 53588 [details]
testcase attached

Comment 16

16 years ago
M18? Nominating mozilla1.0 to put this back on the radar.
Keywords: mozilla1.0

Comment 17

16 years ago
nominating for nsbeta1
Keywords: nsbeta1


16 years ago
Keywords: testcase

Comment 18

16 years ago
Setting target milestone to mozilla1.0 instead of M18, to make sure we review
the values returned by hasFeature() before 1.0. Even though this method is not
in widespread use, it would be good to agree on what we implement successfully
and what not ;-)
Reassigning to jst so that it no longer has the stupid reopened status.
Target Milestone: M18 → mozilla1.0
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [nsbeta2-][nsbeta3+] trivial fix → trivial fix


16 years ago
Blocks: 63345

Comment 19

16 years ago
ADT3 per ADT triage.
Whiteboard: trivial fix → trivial fix [ADT3]

Comment 20

16 years ago
Created attachment 74948 [details]
Proposal for the return values of the hasFeature() method.

This is my proposal for the return values of the hasFeature() method. It was
already submitted to Boris Zbarsky. I'm looking for ideas and feedback from
other people, or unimplemented features that I have overlooked. I want to be
able to stare at developers and say "we return true/false for this module for
the following reasons ..." (that's the goal, anyway).
Feedback is appreciated :-)
We'll always have some bugs. I wouldn't use that as a reason to not say we
support a feature. Even the CSS feature is in reasonable shape now that bz,
caillon et al have been whacking it.

So IMHO we should say we support all the features except those for which we have
made no attempt.

Comment 22

16 years ago
It is one thing to have bugs. It is another to have unimplemented interfaces.
From http://www.w3.org/TR/DOM-Level-2-Core/introduction.html#ID-Conformance:
"An implementation conforms to a DOM Level 2 module if it supports all the
interfaces for that module and the associated semantics".

But then again, it's true that returning false because of one or another
interface that nobody cares about...

Thanks for the feedback Hixie :-)
> * CSSFontFaceRule is not implemented.
> * CSSPageRule is not implemented.

These are not implemented in the style system, so there is no way to do them in
the DOM.  Since the only way they arise in the DOM is via being in a sheet and
they can't be in a sheet because the CSS parser drops them, I'm not sure they
should affect the value returned

> * CSSImportRule is not implemented.
> * CSSCharsetRule is not implemented.

I just checked, and it sure _looks_ like these are implemented...

Comment 24

16 years ago
I hadn't read the full description of the CSSCharsetRule and CSSImportRule,
sorry. Guess I can get rid of those.
About the other two, I guess people don't care if the style system doesn't
implement them. The fact is that we don't support those interfaces. But then
again, the question is,
do we want to return false for a whole module just because of a few non-critical
unimplemented interfaces. Heikki and Hixie say no, so far.

Comment 25

16 years ago
Created attachment 76183 [details] [diff] [review]
Add Core 2.0 and CSS2 to the list of features which we claim to support.

Add CSS2 2.0 and Core 2.0 to the list of "true" features.  This means that we
claim to implement these modules.  If there are known bugs in these features
(and there are including an occasional missing item) we agree to acknowledge
them as bugs and will make sure they are logged as bugs against the module,
even if we have no current plans to fix them due to the difficulty.

The same holds true for all modules on the total current list of supported
features (according to the hasFeature function):

HTML 1.0
HTML 2.0
XML 1.0
XML 2.0Views 2.0
StyleSheets 2.0Core 2.0
CSS 2.0
CSS2 2.0
Events 2.0
MouseEvents 2.0
MouseScrollEvents 2.0
HTMLEvents 2.0
Range 2.0
Attachment #74948 - Attachment is obsolete: true

Comment 26

16 years ago
I request a r= and sr= so that I can commit these changes today.

There is no significant risk in the code changes themselves, as we are just
adding checks to a list that works.

There is some risk to returning true, telling web pages that we support these
features, because it means that web pages that care to check (a simple search in
google found 1000 that  care about core 2.0, 400 that care about CSS (which we
did not change), 100 that care about CSS2) will suddenly start using these
features, which we know are not perfect in their implementation, but we believe
are quite well implemented and we are willing to fix as necessary to make them
as compliant as is practical.
We can neither take proper advantage of our support for these standards nor
reasonably receive feedback about any deficiencies, if we do not claim to
support them as is enabled by this patch.  We have waited long enough.
r=hixie, fwiw
Comment on attachment 76183 [details] [diff] [review]
Add Core 2.0 and CSS2 to the list of features which we claim to support.

Attachment #76183 - Flags: superreview+
Attachment #76183 - Flags: review+

Comment 29

16 years ago
I would have liked that everybody (or a majority, at least) agrees on the
returning values before proposing a patch. But if the netscape people want to
take on this, I submit.
Note that the current returned values don't even make sense, as pointed out by
Martin Honnen in the newsgroups:
specifies that an implementation can only claim to support "MouseEvents" if it
fully supports "UIEvents".
/me bahs

Comment 30

16 years ago
I am trying to help out getting some important stuff landed for Mozilla 1.0 to
give it appropriate exposure.  It is obvious that I am in a bit of a rush but
not such that if you have any reservations about the two features we are turning
on we won't resolve it before getting driver approval and checking in.

As for the two event types you bring up, which I did not propose to change in
this patch, your recent comment exactly contradicts your "Proposal for the
return values of the hasFeature() method, where they exactly match the current
implementation, which I am not changing.  I quote:

Feature name: "UIEvents"
Level: "2.0"
Return value: false
Comment: Reasons why false is suggested:

    * The interfaces are not implemented.

Feature name: "MouseEvents"
Level: "2.0"
Return value: true
Comment: Reasons why false might be returned:

    * No reason.

I wasn't aware of the thread you link to, nor am I inclined to go beyond the two
features which there seems to be a fair amount of agreement on.  If not, please
state your objections.  Everyone I have talked to seems quite willing to accept
them, but I was hoping you would respond here if you had new issues with them.


16 years ago
Attachment #74948 - Attachment is obsolete: false

Comment 31

16 years ago
your help is of course appreciated.
my proposal was just that, a proposal. It was far from perfect, as proved by
your patch (and hixie/heikki's comments), boris' comments, and martin honnen's
comments in the newsgroups. I did it to start the discussion.
I should have added a summary of the discussion in the newsgroups, sorry about
that. Anyway I'm fine with the patch, provided other people are. 
Maybe we should look at the MouseEvents issue though.
Ok, so I spoke to Tom (the main editor of the DOM Events spec), and his claim is
that the feature string "UIEvents" is supposed to flag support for the events
"DOMFocusIn", "DOMFocusOut", and "DOMActivate". The fact that the spec says that
in order to support the "MouseEvents" feature an implementation must also
support the "UIEvents" eature is an error in the spec that Tom was not aware of,
and he did not make that mistake either, one of the other editors most likely
did. Tom's working on what to do about that in the DOM specs.

I'd say for now we take Ray's change and leave the rest as is since the only
reason for changing what we return for "UIEvents" or "MouseEvents" might very
well end up being an errata for the DOM Level 2 Events specification, or changed
in DOM Level 3 Events.

Comment 33

16 years ago
Comment on attachment 76183 [details] [diff] [review]
Add Core 2.0 and CSS2 to the list of features which we claim to support.

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #76183 - Flags: approval+

Comment 34

16 years ago
The patch for core and css2 has now been committed.  It remains to be seen
whether we:

1.  Leave UIEvents / MouseEvents alone.
2.  Change UIEvents
3.  Change MouseEvents
4.  Fix the Events specification

I think we are leaning towards 4.

Comment 35

16 years ago
Comment on attachment 76183 [details] [diff] [review]
Add Core 2.0 and CSS2 to the list of features which we claim to support.

obsoleting patch since it has landed.
Attachment #76183 - Attachment is obsolete: true

Comment 36

16 years ago
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-

Comment 37

16 years ago
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+


16 years ago
Target Milestone: mozilla1.0 → mozilla1.2alpha


16 years ago
Target Milestone: mozilla1.2alpha → mozilla1.3alpha


15 years ago
Target Milestone: mozilla1.3alpha → mozilla1.3final
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs


10 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
File followups if we're mad enough to add more of these.
Last Resolved: 17 years ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.