Closed
Bug 455595
Opened 15 years ago
Closed 5 years ago
deCOMtaminate nsINameSpaceManager
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla63
Tracking | Status | |
---|---|---|
firefox63 | --- | fixed |
People
(Reporter: taras.mozilla, Assigned: qdot)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 3 obsolete files)
This is one of the tasks listed on https://wiki.mozilla.org/Gecko:DeCOMtamination I moved nsNameSpaceManagerImpl into nsINameSpaceManager, got rid of virtual methods. Not sure what else is one is to do. It's pretty trivial and none of these methods are outparamdel-able. Should change the class to not inherit from nsISupports and s/nsCOMPtr/nsRefPtr/ for pointers containing it?
Reporter | ||
Comment 1•15 years ago
|
||
accidentally sent a stale ver
Attachment #338954 -
Attachment is obsolete: true
Attachment #338961 -
Flags: review?(jst)
Comment 2•15 years ago
|
||
Comment on attachment 338961 [details] [diff] [review] cleanup class nsINameSpaceManager : public nsISupports This could totally be a followup bug, but there's no real need to inherit nsISupports here any longer I don't think. And this class should be nsNameSpaceManager now, no need for ns_I_ here any more IMO. + nsresult RegisterNameSpace(const nsAString& aURI, + PRInt32& aNameSpaceID); Got some auto-emacs-indentation magic pixie dust that would help here too? If not, fix this manually before landing :) +nsINameSpaceManager::RegisterNameSpace(const nsAString& aURI, PRInt32& aNameSpaceID) Here, +nsresult nsINameSpaceManager::AddNameSpace(const nsAString& aURI, const PRInt32 aNameSpaceID) and here too. r+sr=jst with that.
Attachment #338961 -
Flags: superreview+
Attachment #338961 -
Flags: review?(jst)
Attachment #338961 -
Flags: review+
Updated•15 years ago
|
Assignee: nobody → tglek
QA Contact: content
Hardware: PC → All
Updated•15 years ago
|
QA Contact: content
Updated•15 years ago
|
QA Contact: content
Reporter | ||
Comment 3•15 years ago
|
||
pushed http://hg.mozilla.org/mozilla-central/rev/92e24ee719b8
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
This broke up the windows and linux leak test builds, so backed out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 5•15 years ago
|
||
To give you more of a hint than that, it fried everything building both accessibility and -enable-shared: SeaMonkey builds everything shared, so all their Linux and Windows builds, Thunderbird only builds unittests shared, so Windows there (and would have been Linux, except it was already busted). I wondered if it just needed a clobber, so depending on when it started, we may or may not have gotten a clobbered Tb Windows check build before the backout.
Comment 6•15 years ago
|
||
Nope, backout made it in before my clobber started.
Comment 7•15 years ago
|
||
Don't forget debug builds are also shared by default.
![]() |
||
Comment 8•15 years ago
|
||
Yeah, so with this patch I get: Undefined symbols: "nsINameSpaceManager::GetNameSpaceURI(int, nsAString_internal&)", referenced from: nsDocAccessible::GetNameSpaceURIForID(short, nsAString_internal&) in nsDocAccessible.o because that function became non-virtual..
Reporter | ||
Comment 9•15 years ago
|
||
jst, is this still a candidate for decomtamination? Once I rename and remove nsISupports, are the downstream projects expected to adapt?
Comment 10•14 years ago
|
||
Is it still possible to deCOM this or should we just close the bug?
Updated•12 years ago
|
Assignee: tglek → Ms2ger
Comment 11•12 years ago
|
||
I don't remember why I stopped working on this bug; this seems to be where I got.
Updated•12 years ago
|
Assignee: Ms2ger → nobody
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → kyle
Assignee | ||
Updated•5 years ago
|
Attachment #338961 -
Attachment is obsolete: true
Assignee | ||
Updated•5 years ago
|
Attachment #606884 -
Attachment is obsolete: true
Assignee | ||
Comment 12•5 years ago
|
||
Most of this was taken care of in bug 458300. However, nsNameSpaceManager still inherited from nsISupports, only for the refcounting bits. We should be able to use NS_INLINE_DECL_REFCOUNTING and finish this off.
Assignee | ||
Comment 13•5 years ago
|
||
Most of the deCOM work was handled in bug 458300, so we just need to use the inline refcounting macro to remove nsISupports. MozReview-Commit-ID: 7npo7RF68Vo
Assignee | ||
Comment 14•5 years ago
|
||
Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7c381d15e95c384e1b250f789c04cb7f5e2cf0c4
Comment 15•5 years ago
|
||
Comment on attachment 8994372 [details] Bug 455595 - Finish deCOMtaminating nsNameSpaceManager Andrea Marchesini [:baku] has approved the revision. https://phabricator.services.mozilla.com/D2309
Attachment #8994372 -
Flags: review+
Comment 16•5 years ago
|
||
Pushed by kmachulis@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/cf462cc971f8 Finish deCOMtaminating nsNameSpaceManager r=baku
Comment 17•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/cf462cc971f8
Status: REOPENED → RESOLVED
Closed: 15 years ago → 5 years ago
status-firefox63:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•