Closed Bug 761613 Opened 12 years ago Closed 12 years ago

Merge nsIPrivateDOMEvent to nsIDOMEvent

Categories

(Core :: DOM: Events, defect)

x86_64
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla16

People

(Reporter: smaug, Assigned: smaug)

References

Details

(Keywords: addon-compat, dev-doc-complete)

Attachments

(2 files, 5 obsolete files)

Attached patch WIP (obsolete) — Splinter Review
Currently C++ code needs to almost always QI to nsIPrivateDOMEvent when dispatching events,
because SetTrusted etc live in that interface. We should just merge nsIPrivateDOMEvent
to nsIDOMEvent.

The patch ends up removing about 240 loc.

https://tbpl.mozilla.org/?tree=Try&rev=a6abab555883
Comment on attachment 630172 [details] [diff] [review]
WIP

Review of attachment 630172 [details] [diff] [review]:
-----------------------------------------------------------------

\o/

::: content/base/src/nsContentUtils.cpp
@@ +3373,1 @@
>    NS_ENSURE_SUCCESS(rv, rv);

Followup to see if we need to return nsresult?

@@ +4638,5 @@
>  //static
>  nsEvent*
>  nsContentUtils::GetNativeEvent(nsIDOMEvent* aDOMEvent)
>  {
> +  return aDOMEvent ? aDOMEvent->GetInternalNSEvent() : nsnull;

Followup to remove this function?

::: content/events/src/nsDOMNotifyPaintEvent.h
@@ +31,5 @@
> +  {
> +    return nsDOMEvent::DuplicatePrivateData();
> +  }
> +  NS_IMETHOD_(void) Serialize(IPC::Message* aMsg, bool aSerializeInterfaceType);
> +  NS_IMETHOD_(bool) Deserialize(const IPC::Message* aMsg, void** aIter);

Can we keep those as they were? Adding [notxpcom] should do that

::: layout/base/nsDocumentViewer.cpp
@@ +1116,5 @@
>    NS_ENSURE_SUCCESS(rv, rv);
>  
>    // XXX Dispatching to |window|, but using |document| as the target.
>    nsCOMPtr<nsIDOMEventTarget> target = do_QueryInterface(mDocument);
> +  event->SetTarget(target);

While you're here, you should be able to drop the QI

::: layout/xul/base/src/nsXULPopupManager.cpp
@@ +436,5 @@
>      // get the event coordinates relative to the root frame of the document
>      // containing the popup.
> +    NS_ASSERTION(aPopup, "Expected a popup node");
> +    nsEvent* event;
> +    event = aEvent->GetInternalNSEvent();

One line, please

::: security/manager/ssl/src/nsSmartCardEvent.cpp
@@ +20,5 @@
>  
>  //NS_DECL_DOM_CLASSINFO(SmartCardEvent)
>  
>  // QueryInterface implementation for nsXMLHttpRequest
>  NS_INTERFACE_MAP_BEGIN(nsSmartCardEvent)

for nsXMLHttpRequest? While you're here.... ;)
Attached patch WIP2 (obsolete) — Splinter Review
Perhaps this compiles on OSX.

https://tbpl.mozilla.org/?tree=Try&rev=1701fce94997
Attachment #630172 - Attachment is obsolete: true
Attached patch WIP3 (obsolete) — Splinter Review
Change some silly browser/chrome tests

https://tbpl.mozilla.org/?tree=Try&rev=245a3d278afa
Attachment #630219 - Attachment is obsolete: true
Attached patch WIP4 (obsolete) — Splinter Review
I'll need to still mark interfaces to builtinclass
Attached patch patchSplinter Review
https://tbpl.mozilla.org/?tree=Try&rev=563255dd88fc

Huge patch but mainly pretty mechanical changes.
Not using nostdcall in the .idl based on the comments from bsmedberg.
Attachment #630566 - Attachment is obsolete: true
Attachment #630588 - Attachment is obsolete: true
Attachment #630654 - Flags: review?(jst)
Attachment #630654 - Flags: review?(jst) → review+
Attached patch up-to-dateSplinter Review
Attachment #631754 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/e011e0440daf
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: 764479
smaug, this patch regressed a bunch of eventlisteners implemented in JS for B2G. jst and cjones vote for backing out if there is no easy fix.
Eh. Sure this didn't regress any event listener implementations. All the event listeners in 
web pages are implemented in JS.
I'm currently updating Instantbird to use Mozilla 16, and the changes in this bug mean I need to update/remove the code using nsIPrivateDOMEvent for a binary component (the binary component using nsIPrivateDOMEvent was original from the MintrayR add-on).

I would have expected this interface removal to be documented on https://developer.mozilla.org/en-US/docs/Firefox_16_for_developers.
Target Milestone: --- → mozilla16
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: