Closed
Bug 165169
Opened 22 years ago
Closed 22 years ago
Ctrl+Shift+Home/End and Ctrl+Home/End do not work
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
FIXED
People
(Reporter: neil, Assigned: mjudge)
References
Details
(Keywords: regression)
Attachments
(1 file)
1.41 KB,
patch
|
kinmoz
:
review+
bryner
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
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•22 years ago
|
||
Was working in Win2k 082608
--> mjudge (selection/caret navigation) brade and akkana this might be a keybindings issue, so I'm cc'ing you too.
Comment 3•22 years ago
|
||
-->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?
Assignee: kin → mjudge
Keywords: regression
Reporter | ||
Comment 4•22 years ago
|
||
*** Bug 165260 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 5•22 years ago
|
||
Making bug more discoverable.
Summary: Select to beginning/end of document don't work → Ctrl+Shift+Home select to beginning (or end) of document doesn't work
Comment 6•22 years ago
|
||
confirmed on linux/x86 20020828. I seem to have lost pageup & pagedown too, in all windows.
OS: Windows 95 → All
Hardware: PC → All
Comment 7•22 years ago
|
||
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•22 years ago
|
||
Clarifying summary to indicate that this does not only affect selection. Is this more lossage from the checkin for bug 4302?
Summary: Ctrl+Shift+Home select to beginning (or end) of document doesn't work → Ctrl+[Shift]+Home/End do not work
Blocks: 1.2a
Comment 9•22 years ago
|
||
*** Bug 166682 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Summary: Ctrl+[Shift]+Home/End do not work → Ctrl+Shift+Home/End and Ctrl+Home/End do not work
Comment 10•22 years ago
|
||
*** Bug 166949 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
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.
Assignee | ||
Comment 12•22 years ago
|
||
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•22 years ago
|
||
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.
Attachment #98160 -
Flags: superreview+
Comment 14•22 years ago
|
||
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=kin@netscape.com 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?
Attachment #98160 -
Flags: review+
Comment 15•22 years ago
|
||
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•22 years ago
|
||
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
Attachment #98160 -
Flags: approval+
Comment 17•22 years ago
|
||
dammit. once again, that should have read "for 1.2alpha." Old habits die hard.
Comment 18•22 years ago
|
||
*** Bug 167266 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 19•22 years ago
|
||
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.
Status: NEW → ASSIGNED
Assignee | ||
Comment 20•22 years ago
|
||
coimmited to trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 21•22 years ago
|
||
*** Bug 167680 has been marked as a duplicate of this bug. ***
Comment 22•22 years ago
|
||
Verifying: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/2002091015 pi
Comment 23•22 years ago
|
||
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.
Status: RESOLVED → VERIFIED
Updated•5 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
•