Opened 12 years ago

Closed 12 years ago

Last modified 8 years ago

#3749 closed defect (fixed)

no blinking caret, only first time into textarea

Reported by: ptbrunet Owned by: haysmark
Priority: high Milestone: 0.9
Component: Dijit - Form Version: 0.9
Keywords: Cc: brunet@…
Blocked By: Blocking:

Description

In the test case for InineEditBox, tab to the text area (the second widget), press enter, there is no blinking caret. Any later use of the text box doesn't have the same failure. The same thing happens if with autoSave off. This is FF only.

Change History (12)

comment:1 Changed 12 years ago by bill

Owner: changed from bill to Douglas Hays

comment:2 Changed 12 years ago by Douglas Hays

Owner: changed from Douglas Hays to haysmark

comment:3 Changed 12 years ago by haysmark

The caret is there, you just can't see it. You can still interact with the textarea using the keyboard as you would expect. So we're setting focus and everything correctly.

comment:4 Changed 12 years ago by haysmark

Resolution: duplicate
Status: newclosed

This is a confirmed FF bug that will be fixed in FF3.

https://bugzilla.mozilla.org/show_bug.cgi?id=167801

comment:5 Changed 12 years ago by ptbrunet

Cc: brunet@… added

The underlying control might be keeping track of the insert position but there is no caret. Both JAWS and Window-Eyes have no idea where the caret is unless it's visible and blinking. As a result there is no feedback to the screen reader user as to where they are when they use any of the nav keys.

comment:6 Changed 12 years ago by Becky Gibson

Resolution: duplicate
Status: closedreopened

reopen based on new information from bill:

Yeah http://trac.dojotoolkit.org/ticket/3749 seems really bad to me too.

But it will be fixed in FF3.0, I hope...

According to the ticket/novella in https://bugzilla.mozilla.org/show_bug.cgi?id=167801*you can workaround this by doing:

position:fixed; position:expression("absolute");

Did we try that?

comment:7 Changed 12 years ago by haysmark

That ticket is not very clear to me. I tried putting many of those expressions on the various tags and nothing happened.

comment:8 Changed 12 years ago by ptbrunet

comment:9 Changed 12 years ago by haysmark

Aaron said there is no way that FF2 will receive this fix. I've already tried all of the workarounds and they really just don't apply to the problems we are having with our DOM layout, even though the symptoms are the same.

comment:10 Changed 12 years ago by bill

Looking again this doesn't seem related to https://bugzilla.mozilla.org/show_bug.cgi?id=167801 which is about an <input> overlapping with a <div> (or other element), but this bug is about the caret in an <iframe>.

https://bugzilla.mozilla.org/show_bug.cgi?id=308736 seems closer but in that bug the caret appears when you start typing.

Anyway, I made it work by just calling setEditFocus() twice, once directly and once in the timer:

		this._setEditFocus();
		setTimeout(dojo.hitch(this, function(){	
			this._setEditFocus();
			this.saveButton.setDisabled(true);
		}), 1);

Check that to make sure it works on all the browsers (or if() it for mozilla) and if no other problems then check in.

comment:11 Changed 12 years ago by bill

Resolution: fixed
Status: reopenedclosed

(In [10046]) InlineEditBox? attempts to set focus twice on its edit widgets, which works around a Firefox render bug involving the caret not appearing in TextArea?. Fixes #3749.

comment:12 Changed 8 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.