282550 - In View Source, CTRL+Home does not go to the start of the file

Status: RESOLVED FIXED

(Toolkit :: View Source, defect)

Description

[Francois Ingelrest]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050216 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050216 Firefox/1.0+

 

Reproducible: Always

Steps to Reproduce:
1. Got to http://www.mozillazine.org/
2. CTRL-U to open View Source
3. Scroll to the middle of the source and click to position the caret there
4. CTRL-Home to go to the start

Actual Results:  
No scroll and the caret does not move

Expected Results:  
The window should have scrolled to the start of the source and the caret should
have been positioned there.

Home, End and CTRL-End work as expected, only CTRL-Home seems broken.

Comment 1

[Eric Seppanen]

Works for me (Windows XP; Firefox 1.0.1).

Note that "as expected" is debatable.  See bug 262668.

Comment 2

[Francois Ingelrest]

I know this works with 1.0.1, I reported this for a trunk build :)

Comment 3

[Nickolay_Ponomarev]

confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050325 Firefox/1.0+

this has worked in 1.0, adding "regression" keyword and asking for
blocking-aviary1.1 

Comment 4

[Wayne Mery (:wsmwk)]

WFM DPalpha2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050715 Firefox/1.0+

flip + flop ?

leaving to someone else to confirm and mark WFM

Comment 5

[Francois Ingelrest]

I just tried with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4)
Gecko/20050719 Firefox/1.0+ :
Home goes to the start of the line
End goes to the end of the line
Ctrl+End goes to the end of the file
Ctrl+Home goes nowhere

Comment 6

[shutdown]

The problem should be in PresShell::CompleteMove() or any code called by it.
http://lxr.mozilla.org/seamonkey/source/layout/base/nsPresShell.cpp#3326

Steps to check:
1. load view-source:http://www.mozilla.org/
2. start Venkman
3. Set the window opening view-source as the Evaluation Object in Venkman
4. evaluate the following code in Venkman:
var I=Components.interfaces, sc=window.QueryInterface(I.nsIInterfaceRequestor).
getInterface(I.nsIWebNavigation).QueryInterface(I.nsIInterfaceRequestor).
getInterface(I.nsISelectionDisplay).QueryInterface(I.nsISelectionController);
5. try evaluating the following things:
sc.completeMove(true, false);  // this should and actually go to the end.
sc.completeMove(false, false); // this should but does not go to the start.

Comment 7

[Mike Connor [:mconnor]]

This is a nice-to-have, but not a blocker by any means.

Comment 8

[hojjats]

Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Comment 9

[JConley]

This now works in trunk.

Would be nice to have in 1.5.0.x - but probably not important enough.

Someone please close as fixed or reassign to 1.5 branch (and opt. mark wontfix).

Comment 10

[Karsten Düsterloh]

0. Mac builds have a similar issue with Cmd-Page Up.
1. This is a problem in SeaMonkey's 1.8.x.y branch also.
2. This was fixed on trunk by bug 272702 on 2005-09-09 (and that check-in fixed it  for Mac/SeaMonkey, too).

Comment 11

[Adam Guthrie]

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

Comment 12

[Aaron P]

20060615 update: this is still not fixed in the Firefox 2 nightlies.

I realize we do not want it in 1.5.0.x, but given that 2.0 is still not yet out and we have a trunk patch to look at for reference, it shouldn't take much work to do.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060615 BonEcho/2.0a3 ID:2006061503

Comment 13

[Simon Bünzli]

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

Comment 14

[Simon Bünzli]

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