In any textarea or rich-edit area:
1. type a couple lines of text
2. click into the middle of the last line
3. hold down shift and press up a couple times to select a couple lines
4. still holding down the shift key, press end
Step 4 moves the end of your selection to the line you clicked in during step 2, which is incorrect. It also does the wrong thing if you hit end without the shift key held down in step for. In that case, the cursor should go to the end of the line where the end of your selection was. Instead it goes to the line you clicked into during step 2.
The same problem applies to the home key, except in step 2 you click in the middle of the first line and then use shift+down in step 3.
This might be a mac vs. pc difference. I'm not even sure what is supposed to be going on here. A clear test case could help.
home/end should move relative the focus of your selection, not the anchor. I think in webkit terms, that's to say, home/end should move relative the extent of the selection and not the base.
This is kind of a mac/pc difference in that home/end on a PC move to the beginning/end of a line and on a mac go to the beginning/end of the edit area. I'm not sure exactly how to provide a clear test case though. I'll put up screenshots of actual vs. expected results.
Created attachment 21959 [details]
using home/end in FF vs. Safari Windows
In that screenshot there's FF and Safari Windows after the following steps:
1. Place the cursor before the word "two"
2. Press shift+down twice (end of the selection is now right before the word "four")
3. Press shift+home (should move the beginning of "line four", instead moves to the beginning of "line two")
Given that home/end do the windows behavior, I think it should really be consistent with other Windows apps in terms of how it works for selected text.
OK, one last comment, the mac analog of moving to the beginning/end of a line (cmd+left/right) is consistent with Safari. So, in short, I think home/end should behave Windowsy on Windows Safari. :)