Closed
Bug 251615
Opened 21 years ago
Closed 21 years ago
Trying to dynamically set tabIndex on some elements causes error
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: arielladog, Assigned: aaronlev)
Details
Attachments
(2 files)
190 bytes,
text/html
|
Details | |
621 bytes,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040715
I know tabIndex wasn't really supported before, but atleast when I tried to
set an element that didn't allow tabIndex, it didn't have any adverse affects
on the JavaScript.
I think it's related to bug 171366
Reproducible: Always
Steps to Reproduce:
1. Create a <div>
2. With JS, try to set the element's tabIndex property
Actual Results:
You'll get an error in the JS console saying that you were trying to set a
property that only has a getter and your script will stop running
Expected Results:
With bug 171366 fixed it should've set and recognized the tabIndex property.
Otherwise, it should've just ignored it and not produced an error.
It works fine for links and it doens't produce an error in 1.7
Reporter | ||
Comment 1•21 years ago
|
||
Reporter | ||
Comment 2•21 years ago
|
||
Related to bug 250006
Assignee | ||
Comment 3•21 years ago
|
||
Good catch, thanks for filing this!
Assignee | ||
Updated•21 years ago
|
Attachment #153665 -
Flags: superreview?(jst)
Attachment #153665 -
Flags: review?(jst)
Comment 4•21 years ago
|
||
Comment on attachment 153665 [details] [diff] [review]
I'm an idiot. 1 line patch.
r+sr=jst :-)
Attachment #153665 -
Flags: superreview?(jst)
Attachment #153665 -
Flags: superreview+
Attachment #153665 -
Flags: review?(jst)
Attachment #153665 -
Flags: review+
Assignee | ||
Comment 5•21 years ago
|
||
Checking in nsIDOMNSHTMLElement.idl;
/cvsroot/mozilla/dom/public/idl/html/nsIDOMNSHTMLElement.idl,v <--
nsIDOMNSHTMLElement.idl
new revision: 1.7; previous revision: 1.6
done
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 6•21 years ago
|
||
Thanks for the quick fix.
I have a quick question, though. When trying to set a readonly property is it
really necessary that it be a JS error and stop the rest of the script?
Couldn't it be just a warning and continue with the processing?
For example, to help cancel events in IE, sometimes I use event.keyCode = 0.
However, in Mozilla, it returns a JS error: "Error: setting a property that
has only a getter" and then stops. It's obviously easy to detect for IE and
only do that for IE, but I just thought it'd be helpful anyways.
Just my two cents,
Ryan
Assignee | ||
Comment 7•21 years ago
|
||
(In reply to comment #6)
> When trying to set a readonly property is it
> really necessary that it be a JS error and stop the rest of the script?
Javascript has a language feature called try/throw/catch. If you wrap things in
try { } and then have the catch statement at the end your script will keep
running through the errors. It's up to you whether to print the javascript
warnings at that point. Look it up in a JS reference. Good luck.
aaronl: that's not precisely accurate, only modern versions of javascript handle
try{} catch(){}. older versions treat them as compiletime errors :) one would
probably want to do <script language="javascript1.3"> or whatever it is that
ensures the browser supports try{}catch(){} before leaping off that cliff...
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•