Closed Bug 402181 Opened 13 years ago Closed 13 years ago

Better error message for captureEvents(), releaseEvents() and routeEvent()

Categories

(Core :: DOM: Events, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: perhans, Assigned: timeless)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

This bug is an ofspring of bug #330494 and especially comment 34 (https://bugzilla.mozilla.org/show_bug.cgi?id=330494#c34) that reads:
Hello,

I wish we could reopen this bug and change the respective error messages

+UseOfCaptureEventsWarning=Use of captureEvents() is deprecated.
+UseOfReleaseEventsWarning=Use of releaseEvents() is deprecated.
+UseOfRouteEventWarning=Use of routeEvent() is deprecated.

to something like

UseOfCaptureEventsWarning=Use of captureEvents() is deprecated. To upgrade your
code, use the DOM 2 addEventListener() method. For more help
http://developer.mozilla.org/en/docs/DOM:element.addEventListener

UseOfReleaseEventsWarning=Use of releaseEvents() is deprecated. To upgrade your
code, use the DOM 2 removeEventListener() method. For more help
http://developer.mozilla.org/en/docs/DOM:element.removeEventListener

UseOfRouteEventWarning=Use of routeEvent() is deprecated. To upgrade your code,
use the DOM 2 dispatchEvent() method. For more help
http://developer.mozilla.org/en/docs/DOM:element.dispatchEvent

The spirit behind the new messages is to be as helpful as possible.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Changing component to Core->DOM:Events
Component: Error Console → DOM: Events
OS: Windows 2000 → All
Product: Firefox → Core
QA Contact: error.console → events
Hardware: PC → All
Version: unspecified → Trunk
CONFIRMING
Status: UNCONFIRMED → NEW
Ever confirmed: true
Voting for this bug :)
Attached patch per reporter... (obsolete) — Splinter Review
Assignee: nobody → timeless
Status: NEW → ASSIGNED
Attachment #312851 - Flags: review?
Attachment #312851 - Flags: review? → review?(Olli.Pettay)
Timeless,

in your patch you give
(...) For more help http://developer.mozilla.org/en/docs/DOM:element.addEventListeners

but it should be rather/instead 

(...) For more help http://developer.mozilla.org/en/docs/DOM:element.addEventListener

No trailing "s"
Attached patch per reporter...Splinter Review
Attachment #312851 - Attachment is obsolete: true
Attachment #312851 - Flags: review?(Olli.Pettay)
Attachment #312859 - Flags: review?(Olli.Pettay)
Comment on attachment 312859 [details] [diff] [review]
per reporter...

looks ok to me
Attachment #312859 - Flags: review?(Olli.Pettay) → review+
Comment on attachment 312859 [details] [diff] [review]
per reporter...

note: it is ok for l10n to fail to catch this change, it's just an improvement to en-US. If they don't want to ship better messages, that's fine. If they have time, that's also nice.
Attachment #312859 - Flags: approval1.9?
Comment on attachment 312859 [details] [diff] [review]
per reporter...

a1.9=beltzner
Attachment #312859 - Flags: approval1.9? → approval1.9+
Comment on attachment 312859 [details] [diff] [review]
per reporter...

mozilla/dom/locales/en-US/chrome/dom/dom.properties 	1.13
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to comment #8)
> (From update of attachment 312859 [details] [diff] [review])
> note: it is ok for l10n to fail to catch this change, it's just an improvement
> to en-US. If they don't want to ship better messages, that's fine. If they have
> time, that's also nice.

At least post to .l10n about this, please, to give them more chances to catch this change.
What's going on here? I thought we're frozen.
This isn't adding strings or making semantic changes (as least in the sense that the error message means anything different).  The string names weren't changed, so other locales will not break or fail.  Don't know if I have a strong opinion either way on this at this point, other than to say that this shouldn't be any different from a typo fix from the perspective of the localizers.
There have been several localizers wondering what to do about this, and they really should worry about different things. We shouldn't be taking RFEs on strings anymore, even if they're just rewording an existing message.

Typos are different, because that makes 2 locales think, string improvements like this one are work for 60. Even if it's not required work, even ignoring it is too much of a hassle right now.

At least that's my take.
You need to log in before you can comment on or make changes to this bug.