Closed Bug 454004 Opened 13 years ago Closed 13 years ago

Ctrl+Home / Ctrl+End don't work in Mail Compose window

Categories

(Core :: DOM: Editor, defect)

defect
Not set
minor

Tracking

()

VERIFIED FIXED
mozilla1.9.1b1

People

(Reporter: tonymec, Assigned: roc)

References

Details

(Keywords: access, regression)

Attachments

(1 file)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080906053021 SeaMonkey/2.0a1pre

Reproducible: Always

Steps to Reproduce:
1. Start writing an email or replying to one.
2. Place the text cursor somewhere in the middle of the text (e.g. by mouse-click)
3. Hit Ctrl+Home or Ctrl+End.

Actual Results:
Nothing happens.

Expected results:
Edit cursor should move to the top (for Ctrl+Home) or the end (for Ctrl+End) of the whole text.

Additional info:
Did not happen on yesterday's nightly.
I see this on shredder on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080906031323 Shredder/3.0b1pre Windows as well. Doesn't seem to be OS specific.
OS: Linux → All
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080907004039 SeaMonkey/2.0a1pre

Problem seems to have disappeared. I propose to resolve this bug WORKSFORME if doesn't reappear within, let's say, a week. Even before that, it can of course be resolved as DUPLICATE if someone finds out which bug, now fixed, caused the problem, or FIXED if it can be found that landing a certain well-defined patch, now rolled back, was the cause.
Whiteboard: [CLOSEME 2008-09-14 see comment #2]
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080908024232 SeaMonkey/2.0a1pre

Bug has reappeared.
Whiteboard: [CLOSEME 2008-09-14 see comment #2]
Am seeing this on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080908033053 Shredder/3.0b1pre still.
Keywords: access
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080909002343 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080910003607 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

(bug still there)

This is not in the Editor product: (browser) textareas still work.

NB:
Afaicr, this kind of bug already happened.
Any way to create an automated test for it ?
Severity: normal → minor
Component: Editor → Composition
Product: Core → MailNews Core
QA Contact: editor → composition
Flags: blocking-thunderbird3.0b1?
(In reply to comment #5)
> This is not in the Editor product: (browser) textareas still work.

(Actually, it could likely be, but we don't know that yet, do we ? :-|)

> NB:
> Afaicr, this kind of bug already happened.

Like (Core)
Bug 394264 - Ctrl+Home doesn't work, in the body of a message being composed
for example.

> Any way to create an automated test for it ?

That bug still has "in-testsuite=?"...
Flags: blocking-thunderbird3.0b1?
Flags: blocking-thunderbird3.0b1+
Flags: blocking-thunderbird3+
Doesn't work in the midas demo (http://www.mozilla.org/editor/midasdemo/) either. I didn't check if it used to...
Hardware: PC → All
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080910005241 SeaMonkey/2.0a1pre ID:20080910005241

According to a post by Barry Gilmour on the mozilla.dev.apps.seamonkey newsgroup, doesn't work in the (Web) Composer window either.
Serge: I see your regressionwindow-wanted keyword, so let's recap the above:
- Until the 2008-09-05 nightly included the bug was never seen
- 2008-09-06 had it (Sm & Tb)
- 2008-09-07 didn't (at least for Sm)
- 2008-09-08 had it, and so did all following builds. (Sm & Tb again)
I suppose hourly builds could be used to refine the window, but first, is there a relevant patch which was landed between Sep. 5 and 6 nightlies, rolled back the next day, and landed again (maybe in slightly modified form) the day after?
(In reply to comment #5)
> This is not in the Editor product: (browser) textareas still work.

(In reply to comment #7)
> Doesn't work in the midas demo (http://www.mozilla.org/editor/midasdemo/)
> either. I didn't check if it used to...

Does it work with midasdemo with Firefox nightlies? If not (which seems likely) then this does technically belong in Core:Editor and request blocking-Fx3.1?
Trying to answer comment 9: the ranges that I get from the above build IDs translate into the following hg commands:

hg log -d "2008-09-06 05:30:21 -0700 to 2008-09-07 00:40:39 -0700"
hg log -d "2008-09-07 00:40:39 -0700 to 2008-09-08 02:42:32 -0700"

(SM build IDs are also in PDT, right? There's also the problem that the hg dates are really the local commits IIUC and not the dates where things become visible in mozilla-central.)

In the first range, the only backout I see is changeset 18888:75c0f6a36941 that says "Backing out changesets 75919d3eb3d0 and 14ce7619e9c1 due to test failures", both are apparently related to Bug 243519. Something of that bug landed (again?) with changeset 18953:679778dd198f in the second range.
(In reply to comment #11)
> (SM build IDs are also in PDT, right? There's also the problem that the hg
> dates are really the local commits IIUC and not the dates where things become
> visible in mozilla-central.)

All build IDs of official build machines are "Mozilla Standard Time", i.e. Pacific Time, yes. And for the problem with local commits vs. actual pushes we have http://hg.mozilla.org/mozilla-central/pushloghtml (and the same for comm-central), which lists by whom and when those changesets were actually _pushed_ to the hg repo.

Still, finding out if it happens in core code like described in comment #10 would probably be very helpful there.
OK, thanks. The pushloghtml page basically confirms what I said in comment 11. I didn't see any similar back-out/check-in-again procedure for comm-central.

Testing Linux Firefox nightlies with http://www.mozilla.org/editor/midasdemo/:

Gecko/20080905020631 Minefield/3.1b1pre   works
Gecko/20080906020434 Minefield/3.1b1pre   works
   original push Sat Sep 06 02:35:22 2008 -0700
   backout       Sat Sep 06 05:35:32 2008 -0700
Gecko/20080907020415 Minefield/3.1b1pre   works
   checkin again Mon Sep 08 01:41:35 2008 -0700
Gecko/20080908020331 Minefield/3.1b1pre   broken
Gecko/20080911020347 Minefield/3.1b1pre   broken

This still conincides with Bug 243519 which was originally push 2008-09-06 02:35:22, backed out before the next nightly at 2008-09-06 05:35:32 and pushed again at 2008-09-08 01:41:35.

roc, perhaps you can comment on this?
Blocks: 243519
Component: Composition → Editor
Flags: blocking-thunderbird3.0b1+
Flags: blocking-thunderbird3+
Product: MailNews Core → Core
QA Contact: composition → editor
It probably is that patch, although I'm not sure how.
Assignee: nobody → roc
Flags: blocking1.9.1?
In reply to comment #14:
Let's bee pragmatic. I see two possibilities to check it:
- which were the tinderbox-builds bracketing the suspicious landings and rollbacks? Testing hourlies rather than nightlies can narrow down the range.
- if a test build can be compiled (not on the Mozilla tinderbox/ftp servers) with the suspicious patch rolled out (and no other changes), and it doesn't show this bug, that would clinch it.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080912010509 Minefield/3.1b1pre] (home, optim default) (W2Ksp4)

I compiled a backout of bug 243519 over a build I did earlier today:
http://www.mozilla.org/editor/midasdemo/ works again.
This presshell code is crazy. Instead of poking around the frame tree, let's just get what we want from the frame constructor.

I went a bit crazy myself and wrote a bunch of editor command tests.
Attachment #338261 - Flags: superreview?(mats.palmgren)
Attachment #338261 - Flags: review?(mats.palmgren)
(That code broke because I made the root element frame be an nsBlockFrame instead of the nearly-identical nsAreaFrame.)
Hmm, home/end or ctrl+home/end don't work in view source anymore. Smae bug?
(In reply to comment #19)
> Hmm, home/end or ctrl+home/end don't work in view source anymore. Smae bug?

Could be. Here too, they don't work in View Source, neither in the mailer nor in the browser; note that I have HTML Validator installed (which does some things to the browser's View Source window).

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080911003949 SeaMonkey/2.0a1pre
P.S. Home/End without Shift or Ctrl do work here (Home = start of line; End = end of line).
Comment on attachment 338261 [details] [diff] [review]
fix
[Checkin: Comment 28]

Looks great!  r+sr=mats
Attachment #338261 - Flags: superreview?(mats.palmgren)
Attachment #338261 - Flags: superreview+
Attachment #338261 - Flags: review?(mats.palmgren)
Attachment #338261 - Flags: review+
Blocks: 454522
No longer blocks: 454522
Duplicate of this bug: 454522
For several days already, selection in the Mail Compose window has become blue FG on white BG which makes it very hard to use because not easy to tell apart from the white BG, black FG of normal text. Don't know if related with this bug. Selection works OK in Browser and in the Folder List and Message List panes of my 3-pane Mail window (which is actually 2-pane since I keep the preview pane closed).

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080916001423 SeaMonkey/2.0a1pre
Tony, that's bug 455217. Separate bugs for separate issues. ;-)
Could we get the patch checked in? This is blocking the SeaMonkey 2 Alpha 1 release at the moment, which else is frozen and waiting for fixes to the last couple of blockers.
Anyone can feel free to check this in. I haven't because of time constraints and the tree being closed a lot in the last couple of days.
Keywords: checkin-needed
Comment on attachment 338261 [details] [diff] [review]
fix
[Checkin: Comment 28]

http://hg.mozilla.org/mozilla-central/rev/90c793b9cea1
Attachment #338261 - Attachment description: fix → fix [Checkin: Comment 28]
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: blocking1.9.1?
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b1
Flags: in-testsuite+
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1221694536.1221698224.13763.gz
WINNT 5.2 mozilla-central qm-win2k3-03 dep unit test on 2008/09/17 16:35:36
and
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1221694204.1221698156.13552.gz
Win2k3 comm-central dep unit test on 2008/09/17 16:30:04
have
[
*** 34138 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/base/tests/test_selection_move_commands.xul | node after cmd_selectWordNext - got [object Text], expected [object HTMLBodyElement]
*** 34139 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/base/tests/test_selection_move_commands.xul | offset after cmd_selectWordNext - got 0, expected 1
*** 34145 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/base/tests/test_selection_move_commands.xul | cmd_movePageUp works - got 14, expected 12
*** 34155 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/base/tests/test_selection_move_commands.xul | cmd_selectPageUp works - got 14, expected 12
]

These seem to be Windows only failures.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I disabled the failing tests and filed bug 455818 to get them working on Windows.
The patch was not backed out, so this bug remains fixed.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
(In reply to comment #25)
> Tony, that's bug 455217. Separate bugs for separate issues. ;-)

ah, thanks. Not always obvious to me which issues are really "separate" and due to different coding errors. :-)
(In reply to comment #31)
> The patch was not backed out, so this bug remains fixed.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080917231617 SeaMonkey/2.0a1pre

I verify that the problem has disappeared in this Linux tinderbox-build. Windows and Mac, anyone?
Still broken for me:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080917030604 Shredder/3.0b1pre
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The patch was pushed on "Wed Sep 17 16:28:42 2008 -0700" (looking at http://hg.mozilla.org/mozilla-central/pushloghtml). So that's after your Shredder build was created, right?
In another hour or so next nightly will be released and we can verify this on Test day: https://wiki.mozilla.org/Thunderbird:QA_TestDay:2008-09-18
As far as I can tell, Aaron tested a build from before this patch was checked in.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
I've verified that this problem has disappeared on my windows build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080918034633 Shredder/3.0b1pre

I don't know if/how I can manually test the failed tests from comment #29.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080918002409 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

V.Fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.