Freeze more DOM interfaces

RESOLVED FIXED in mozilla1.3beta

Status

()

P1
major
RESOLVED FIXED
16 years ago
10 years ago

People

(Reporter: chak, Assigned: jst)

Tracking

({topembed+})

Trunk
mozilla1.3beta
x86
Windows 2000
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [HAVE FIX])

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
The following DOM interfaces need to be frozen:

nsIDOMHTMLElement
nsIDOMHTMLImageElement
nsIDOMHTMLBaseElement
nsIDOMHTMLInputElement
nsIDOMHTMLBodyElement
nsIDOMHTMLAreaElement
nsIDOMHTMLIFrameElement
nsIDOMHTMLFrameElement
nsIDOMHTMLAppletElement
nsIDOMHTMLDocument
nsIDOMHTMLCollection
nsIDOMRange
nsIDOMMouseEvent
(Reporter)

Updated

16 years ago
Keywords: topembed+
Priority: -- → P1
Target Milestone: --- → mozilla1.2alpha
(Reporter)

Updated

16 years ago
Blocks: 157137

Comment 1

16 years ago
Adding a few more interfaces that are missing here but were discussed/agreed as
ready to freeze at the 9/5/02 meeting (see
news://news.mozilla.org:119/3D764F94.8040606@netscape.com)

nsIDOMAbstractView
nsIDOMCSSPrimitiveValue
nsIDOMCSSRule
nsIDOMCSSRuleList
nsIDOMCSSStyleSheet
nsIDOMCSSStyleDeclaration
nsIDOMCSSValue
nsIDOMCSSValueList
nsIDOMDocumentRange
nsIDOMDocumentStyle
nsIDOMDocumentView
nsIDOMEventReceiver 
nsIDOMHTMLImageElement 
nsIDOMMediaList
nsIDOMStyleSheet
nsIDOMUIEvent

There may be others ready to be frozen as well.  Johnny, the 1.2 branch is going
to be cut pretty soon.  Are these on track?
(Assignee)

Updated

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

Comment 2

16 years ago
Created attachment 110380 [details] [diff] [review]
Fix

This patch freezes everything but nsIDOMEventReceiver, which is an internal
interface that AFAICT no embedders should ever need to use.
(Assignee)

Updated

16 years ago
Attachment #110380 - Flags: superreview?(peterv)
Attachment #110380 - Flags: review?(harishd)
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX[
Target Milestone: mozilla1.3alpha → mozilla1.3beta

Comment 3

16 years ago
Comment on attachment 110380 [details] [diff] [review]
Fix

r=harishd
Attachment #110380 - Flags: review?(harishd) → review+
Comment on attachment 110380 [details] [diff] [review]
Fix

>Index: dom/public/idl/html/nsIDOMHTMLDocument.idl
>===================================================================

-document exception on cookie
-document why open is noscript

>Index: dom/public/idl/range/nsIDOMRange.idl
>===================================================================

-document exception on endContainer
		       endOffset
		       collapsed
-rename the "parent" argument in setStart to "refNode"
-in the comment "// CompareHow Group", remove "Group"
Attachment #110380 - Flags: superreview?(peterv) → superreview+
Johnny, before you land this for nsIDOMHTMLIFrameElement, could you at least
have one more look at bug 170554?  I think we do want a focus() method, but do
we want it in this iface, or in a NS iface?
(Assignee)

Comment 6

16 years ago
If we'd want a focus() method on [i]frame's we'd want that in
nsIDOMNSHTMLIFrameElement, not in nsIDOMHTMLIFrameElement.
Whiteboard: [HAVE FIX[ → [HAVE FIX]
That's what I figured, but just thought I'd check.
(Assignee)

Comment 8

16 years ago
Fixed, except that the interface nsIDOMEventReceiver is *not* frozen, that's an
internal interface that no embedders should rely on, therefore it should not
need to be frozen.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
maybe it's a good idea to add a comment in nsIDOMEventReceiver saying that it is
internal, so that embedders don't rely on it and so that it doesn't accidently
gets frozen in the future. (i guess this applies to a lot of interfaces though)

Updated

10 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.