165169 - Ctrl+Shift+Home/End and Ctrl+Home/End do not work

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[[e-mail]]

Using Build ID: 2002082704 (regression from the day before?)
Steps to reproduce problem:
1. Open a page in Editor (or type some junk into a new page)
2. Press Ctrl+Shift+Home (or whichever platform key it is)
3. Press Ctrl+Shift+End

Expected results: selection changes

Actual results: nothing happens

Additional information: the keys do work in <input> and <textarea>

More information:
From JS, the following does work:
var commandDispatcher = document.commandDispatcher
var controller = commmandDispatcher.getControllerForCommand("cmd_selectTop")
controller.isCommandEnabled("cmd_selectTop") returns true
controller.doCommand("cmd_selectLineBegin") works
But controller.doCommand("cmd_selectTop") throws NS_NOINTERFACE

Further information:
I have customized the browser keybindings to add cmd_selectTop/Bottom keys.
These have also stopped working.

Comment 1

[Nicholas Allen]

Was working in Win2k 082608

Comment 2

[kinmoz]

--> mjudge (selection/caret navigation)

brade and akkana this might be a keybindings issue, so I'm cc'ing you too.

Comment 3

[Kathleen :Brade]

-->mjudge per kin

Is this on all platforms?
Possibly this should go to Editor:Composer since it sounds like this problem is
specific to Composer?

Comment 4

[[e-mail]]

*** Bug 165260 has been marked as a duplicate of this bug. ***

Comment 5

[[e-mail]]

Making bug more discoverable.

Comment 6

[Calum Mackay]

confirmed on linux/x86 20020828.

I seem to have lost pageup & pagedown too, in all windows.

Comment 7

[Boris 'pi' Piwinger]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/2002082818

This also happens for CTRL-Home and CTRL-End, AFAICS everywhere, Browser,
MailNews-Composer etc. Maybe someone can extend the summary suitably, I don't
have a good idea.

pi

Comment 8

[Brian Ryner (not reading)]

Clarifying summary to indicate that this does not only affect selection.  Is
this more lossage from the checkin for bug 4302?

Comment 9

[Boris 'pi' Piwinger]

*** Bug 166682 has been marked as a duplicate of this bug. ***

Comment 10

[Daniel Wang]

*** Bug 166949 has been marked as a duplicate of this bug. ***

Comment 11

[Dimitrios]

It was working before the fix for bug 4302. Minding you that Ctrl+Home, Ctrl+End
don't work in composing windows only. They are working as expected in normal
browser or message windows.

Comment 12

[mjudge]

Attachment: nsPresShell.cpp in layout/html/base/src

patch what will search for the topmost areaframe before calling off to peek
offset.  The assumption before was that the top most scrolled frame must have a
line iterator. this was wrong. we needed the topmost nsAreaFrame.

Comment 13

[Brian Ryner (not reading)]

Comment on attachment 98160 [details] [diff] [review]
nsPresShell.cpp in layout/html/base/src

Just a few comments, all minor:

>   if (!frame)
>     return NS_ERROR_FAILURE;
>+//we need to get to the area frame.
>+  nsCOMPtr<nsIAtom> frameType;

Fix the indenting of the comment.

>+  do 
>+  {
>+    frame->GetFrameType(getter_AddRefs(frameType));
>+    if (frameType.get() != nsLayoutAtoms::areaFrame)

No need to use .get() for atom comparisons.

>+    {
>+      result = frame->FirstChild(mPresContext, nsnull,&frame);

Use consistent spacing (space after the last comma).

>+      if (NS_FAILED(result) || !frame)
>+        break;
>+    }
>+  }while (frameType.get() != nsLayoutAtoms::areaFrame);

Space between } and while.  Lose the .get().

Fix these and sr=bryner.

Comment 14

[kinmoz]

Comment on attachment 98160 [details] [diff] [review]
nsPresShell.cpp in layout/html/base/src

I didn't like the fact that we're only traversing the down the first-child arc
of the tree underneath the canvas frame, but I couldn't come up with a test
case where I could make the canvas have more than one child, so the current
reality looks like canvas will only have one child the HTML node's area frame.

r=[e-mail] with the changes bryner asked for ... mjudge do the changes
you made in nsTextControlFrame.cpp have the same problem or is the client data
in the view the actual div area frame?

Comment 15

[kinmoz]

Comment on attachment 98160 [details] [diff] [review]
nsPresShell.cpp in layout/html/base/src

By the way, please make sure these changes also work for XML documents. And
please add a comment that states *why* the traversal down to an area frame is
necessary.

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 98160 [details] [diff] [review]
nsPresShell.cpp in layout/html/base/src

a=asa (on behalf of drivers) for checkin to 1.1

Comment 17

[Asa Dotzler [:asa]]

dammit. once again, that should have read "for 1.2alpha." Old habits die hard.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 167266 has been marked as a duplicate of this bug. ***

Comment 19

[mjudge]

works for the files we currently edit just fine. anything besides an area frame
wouldnt work for complete move anyway. the text area frame doesnt have this problem.

I just hope to god I have the correct number of spaces after my commas and
before my comments...  checkin of code very soon.

Comment 20

[mjudge]

coimmited to trunk.

Comment 21

[Michael Lefevre]

*** Bug 167680 has been marked as a duplicate of this bug. ***

Comment 22

[Boris 'pi' Piwinger]

Verifying: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/2002091015

pi

Comment 23

[sairuh (rarely reading bugmail)]

vrfy'd fixed using 2002.09.16.08 comm trunk builds.

on win2k and linux rh72: ctrl-shift-home/end selected from cursor to beginning
and and (respectively) of compose area.

on mac os 10.1.5: cmd-shift-up/down arrows accomplished the same thing.