Deprecate DOMException.code

RESOLVED FIXED in mozilla14

Status

()

defect
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: emk, Assigned: emk)

Tracking

({dev-doc-complete})

Trunk
mozilla14
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

7 years ago
DOMException.code is deprecated per DOM4 spec.
(Assignee)

Comment 1

7 years ago
Posted patch patch (obsolete) — Splinter Review
Adding a deprecation warning.
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Attachment #613190 - Flags: review?(jonas)
Are we planning to remove support? It seems not too useful to warn for things that aren't broken, and won't be.
(Assignee)

Comment 3

7 years ago
If an existing IndexedDB/File API code uses .code to identify the error, it will be surely broken.
Also, we used to removed many non-broken things (taintEnabled, xmlVersion, isSameNode, etc.)
That said, I have no plan to remove .code at the moment (then what the DOM4 deprecation means?).
(Assignee)

Updated

7 years ago
Depends on: 730161
I'm a little bit worried about warning here.

I agree that for code that uses IndexedDB or FileAPI exceptions, we are going to break people that are using DOMException.code.

However I'd expect it to be much much more common to use DOMException.code in code that uses older DOM APIs, such as normal Node manipulation etc. For those people, warning them doesn't do a lot of good. They likely need their code to work on older browsers where .name isn't available or doesn't have the new standardized names, and writing different code paths for Gecko is likely just a pain with no real gain.

So basically I'm worried that we're going to stick a warning in people's developer console, with no good alternative for what they should used instead. So I'm worried people are just going to ignore this warning which lessens the value of warnings in general.

So basically I think we should wait with checking this patch in until in a year or two when it would make more sense for developers to use .name for all exceptions.
(Assignee)

Comment 5

7 years ago
Then what about this? This patch relies on patches of bug 730161.
Attachment #613190 - Attachment is obsolete: true
Attachment #613190 - Flags: review?(jonas)
Attachment #613428 - Flags: review?(jonas)
(Assignee)

Updated

7 years ago
Attachment #613428 - Attachment description: Deprecate DOMException.code only the code was changed (IndexedDB or File API) or is useless (zero) → Warn use of DOMException.code only when the code was changed (IndexedDB or File API) or is useless (zero)
Comment on attachment 613428 [details] [diff] [review]
Warn use of DOMException.code only when the code was changed (IndexedDB or File API) or is useless (zero)

SOLD to the awesome Kimura-san!
Attachment #613428 - Flags: review?(jonas) → review+
(Assignee)

Updated

7 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/4b667b134bc7
Flags: in-testsuite-
Keywords: checkin-needed
Target Milestone: --- → mozilla14
(In reply to Ryan VanderMeulen from comment #7)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/4b667b134bc7

Backed out whole merge for bustage per Yoric (Bug 743574):

https://hg.mozilla.org/integration/mozilla-inbound/rev/12e42fb8e321
Target Milestone: mozilla14 → ---
Disregard that; PEBKAC. Did not get backed out. I misread TBPL.
Keywords: checkin-needed
Target Milestone: --- → mozilla14

Comment 10

7 years ago
https://hg.mozilla.org/mozilla-central/rev/4b667b134bc7
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 11

7 years ago
Backed out: https://hg.mozilla.org/mozilla-central/rev/af7263971ad4
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Ehsan Akhgari [:ehsan] from comment #11)
> Backed out: https://hg.mozilla.org/mozilla-central/rev/af7263971ad4

This bug is cursed.
(In reply to Ehsan Akhgari [:ehsan] from comment #11)
> Backed out: https://hg.mozilla.org/mozilla-central/rev/af7263971ad4

Ehsan, that changeset doesn't appear to have anything to do with this bug. Furthermore, per comment 9, this was never actually backed out AFAIK.
(Assignee)

Comment 14

7 years ago
Closing again because this is not really backed out.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.