Closed Bug 1007680 Opened 6 years ago Closed 6 years ago

Home, End, Up and Down keys no longer work when editing a table cell

Categories

(Toolkit :: XUL Widgets, defect, major)

defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 777832
Tracking Status
firefox29 --- affected
firefox30 --- affected
firefox31 --- affected
firefox32 --- affected
firefox-esr24 --- ?

People

(Reporter: gaubugzilla, Unassigned)

References

Details

(Keywords: regression)

Steps to reproduce:

1. Click the star icon in toolbar to bookmark a page.
2. Click the same icon again to open bookmark editor.
3. Click the dropdown button right of the folder selector.
4. Click the plus icon to create a new folder (allows you to enter the name of the folder within the <tree> widget).
5. Try pressing Home, End, Up and Down arrow keys.

Expected results:

The caret moves.

Actual results:

Nothing happens, the events are ignored. This affects all editable <tree> widgets and is a regression from bug 950373 (these changes: http://hg.mozilla.org/mozilla-central/rev/b57f9be43a50#l2.89). I verified that changing the event attribute for the <handler> tags in tree.xml from "keydown" back to "keypress" fixes this issue.

The problem is that these handlers have "accel any" as their modifiers attribute meaning that they will apply even if no modifier keys are pressed. And they have preventdefault="true" meaning that they will unconditionally prevent the default action. Note that the functions called there like _moveToEdge() will actually check this._editingColumn and return early - but that doesn't matter, the event has been canceled already.

IMHO the best solution would be to call event.preventDefault() explicitly in these functions, only if they actually handled the event.
Blocks: abp
Indeed, this bug must be a regression of it.

<tree> element is now handling keydown event because keypress event might be suppressed to be fired. However, ns*Editor handles the keys at keypress event. Ideally, ns*Editor should handle key events except printable keys at keydown event. But we need a lot of work for doing so.

I'll look for a hack for this, next week. Thank you for your report.
???
I can reproduce in Firefox29.0 with fresh profile.
https://hg.mozilla.org/releases/mozilla-release/rev/f60bc49e6bd5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20140421221237

I think this is Bug 777832
(In reply to Alice0775 White from comment #2)
> ???
> I can reproduce in Firefox29.0 with fresh profile.

Ouch, you are right - I seem to have found a bad example, the bookmark editor doesn't support Home/End keys in Firefox 29 either. However, adding a filter in Adblock Plus preferences is only affected from Firefox 30 upwards. And even more importantly, partially reverting the change from bug 950373 in the current nightly fixes both Adblock Plus preferences and the bookmark editor. So there must be some other issue affecting the bookmark editor in Firefox 29.
Never mind, this is indeed a duplicate of bug 777832 and not a regression. The reason it worked in Adblock Plus preferences is an ancient hack we added to work around just that bug - but we only stopped propagation of keypress events there, not keydown events.
No longer blocks: abp
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 777832
You need to log in before you can comment on or make changes to this bug.