Context menu key to fix spellings is on wrong line of textarea

[Jeremy]

Binary package hint: firefox

Details and reproduction at http://wwwb.forbidden.co.uk/~jbj/firefoxbug.html

Summary is that pressing the Context Menu or Right-Click key on a Windows keyboard in a textarea will sometimes give spelling corrections for words on different lines (or not give corrections at all for the word under the cursor).

ProblemType: Bug
Architecture: i386
Date: Sun Aug 26 00:51:59 2007
DistroRelease: Ubuntu 7.04
Package: firefox 2.0.0.6+1-0ubuntu1
PackageArchitecture: i386
SourcePackage: firefox
Uname: Linux tufnell 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

[Brettw-gmail (brettw-gmail)]

Seems to work for me on my Linux branch build.

[Adam Guthrie (ispiked)]

I can reproduce in a tinderbox build and my own branch build from this morning. I created a new profile just to test this.

[Adam Guthrie (ispiked)]

This regressed on branch Linux and Mac between 2006-05-15-04 and 2006-05-16-04. Incidentally, this time period is when the fix for bug 337368 landed on branch!

Check-ins: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-15+03&maxdate=2006-05-16+05&cvsroot=%2Fcvsroot

I'm going to back out the patch for bug 337368 and see if this fixes things.

[Gavin Sharp (gavin-sharp)]

WFM
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060731 BonEcho/2.0b1

[Adam Guthrie (ispiked)]

Backing out the patch for bug 337368 did not fix this for me.

[Pilgrim-gmail (pilgrim-gmail)]

Confirming previous comments that this does not affect Windows builds (tested 2006-08-02 branch).

[Adam Guthrie (ispiked)]

I just verified that this is broken on current tinderbox builds for both branch and trunk on both Mac OS X and Linux (FC5).

I also verified that the regression window I mentioned in comment 3 is the same for Mac OS X (on the 1.8 branch).

[Adam Guthrie (ispiked)]

Created an attachment (id=232021)
testcase

I can reliably reproduce this bug on Windows trunk using this testcase.

[Martijn-martijn (martijn-martijn)]

(In reply to comment #8)
> I can reliably reproduce this bug on Windows trunk using this testcase.

Yeah, I can reproduce this too on current windows trunk build.

[Martijn-martijn (martijn-martijn)]

(In reply to comment #9)
> Yeah, I can reproduce this too on current windows trunk build.

However, on current 1.8.1 branch builds, it seems to work just fine.

[Adam Guthrie (ispiked)]

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

[Pkasting (pkasting)]

I've just gotten a user report of this on:
Mozilla/5.0 (Windows; I; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0
If this is reproducibly broken in the 2.0 RCs, that seems bad, though certainly not a blocker -- we'd probably want to try for a .1 fix though.

[Bugzilla-tuxmachine (bugzilla-tuxmachine)]

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

[Yarma22 (yarma22)]

(In reply to comment #13)
> *** Bug 358337 has been marked as a duplicate of this bug. ***

Sorry for the duplicate bug, I'm hopeless at searching in Bugzilla.
What's the hell ?! I don't understand, I can't reproduce the bug anymore... And I don't have any explanation !

[Bugzilla-tuxmachine (bugzilla-tuxmachine)]

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

[Brettw-gmail (brettw-gmail)]

I can confirm I've seen this problem on the branch (I thought it was only on trunk). It seems not to happen very often though, but it seems like a big problem if it happens at all.

Related is that the context menu doesn't appear if you have the cursor right before the word. This can be annoying for users who select the whole word moving backwards and use the context menu key.

Possibly the fix is if the current pixel does not have a misspelling under it, to check the pixel above and to the right. This might fix both of the problems. Unfortunately, I don't have time to work on this right now.

[Philringnalda (philringnalda)]

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

[Pgoiffon (pgoiffon)]

Please note that Windows users can use one of the two Windows key on their keyboard : the Windows application key. Use of this key is very common for people used to keyboard shortcuts. On Windows it was Word that made inline spell checking popular, and the windows application key was created I believe having this particularly in mind.

[Ruediger-lahl (ruediger-lahl)]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070214 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070214 SeaMonkey/1.5a

If spellchecker underlines a misspelled word you have to place the cursor in the word above the misspelled word to get the contextmenu from the keyboard. Rightclick with mouse works fine.

Reproducible: Always

Steps to Reproduce:
1.Write two lines with a misspelled word in the second line
2.spellchecker underlines the misspelled word.
3.place the cursor on the misspelled word and use the key between the right ALT and Ctrl key (Windows keyboard).
4.no corrections for the word are shown.
5.place the cursor in the word above the misspelled word and hit the key
6.the corrections in the context menu are shown.
Actual Results:
no corrections are shown.

Expected Results:
the corrections should be shown.

This bug also affects TB3.0a1.

The bug only affects the keyboard action. Rightclick with mouse on the misspelled word works as expected.

Bug appears first in my SM-Trunk-builds from January the 18.

[private_lock (private-lock)]

Spelling suggestions in context-menu depend on cursor-position!

In a fresh profile with only the en-US dictionary open a page with a textarea and paste everything between the quotation marks:

"A nice english text. hjtr
with alot of errors
f gf< djg fxgh xdgt bydt
sdfbgty xt shtdbgtad gteaah tdyxgd he
ADHT 5HZ RYDGRDG Whtsd hrhxf hjtzjs
 hjzfdhj fzcj zdfhj fxchj ztd
gfg jzfjfxth jjdz7 7te gtd dfsg aevgyd gftst hsetrfagtydr earAt rsg xydthzdY 4g
rsaz ysrgt ysgtrrydgt xdth xfhdxyh zeraz hydgysrzt ajhydg Sgt ydxhz zgju <ct hxt
hz chg ctrhz xtch t tfj tfugik zfik ikufzt ted trsht dhfdhj zj rsd hujdtrj hjtr
 hjtr "

- place cursor into last word "hjtr" and invoke context menu via context-menu-key or shift+F10
- notice the first line reads "no suggestions available"
- place cursor into second last word "hjtr"
- spelling is not triggered at all
- jump to first line last word "hjtr" and see the real list of suggestions
- rightclick on any of the "hjtr" and see the expected list of suggestions

This example is highly instable. Back in my normal profile it does not work anymore, but in a fresh profile I could reproduce it. Notice also, that it depends on the direction / location, the cursor is coming from. In addition the lines of garbage prior to the miss-spelling have a major influence. Try adding or deleting some of it.

In addition, I sometimes managed to get suggestions, that clearly belong to the word before or after. In no case I could observe an error on the very first miss-spelling in a textarea. To me it seems, as if the "spelling-cursor" is some 10 characters off from the visibile "text-insertion-character".

[private_lock (private-lock)]

Sorry ... forgot to append the version numbers:

Linux 2.6.18.8-0.1-default
openSUSE 10.2
KDE 3.5.5 "release 45.2"
GTK gtk2-2.10.6-24.2
Firefox/2.0.0.2
Gecko/20061023
Java 1.6.0_01-b06

[mikamikaze (mikamikaze)]

This bug is happening in Firefox 2.0.0.4, windows XP SP2 too.
I got this on 2 differents machines.

[Jeremy (jeremy-durge)]

Binary package hint: firefox

Details and reproduction at http://wwwb.forbidden.co.uk/~jbj/firefoxbug.html

Summary is that pressing the Context Menu or Right-Click key on a Windows keyboard in a textarea will sometimes give spelling corrections for words on different lines (or not give corrections at all for the word under the cursor).

ProblemType: Bug
Architecture: i386
Date: Sun Aug 26 00:51:59 2007
DistroRelease: Ubuntu 7.04
Package: firefox 2.0.0.6+1-0ubuntu1
PackageArchitecture: i386
SourcePackage: firefox
Uname: Linux tufnell 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

[lucia_engel (lucia-engel)]

Thank you for the bug report. Could you please try to reproducing the error with a new profile by following the instructions on https://wiki.ubuntu.com/MozillaTeam/Bugs

Also, please answer these questions:
Which flash package do you have installed?
Which Java package do you have installed?
Which firefox extensions do you have installed?

This will greatly aid us in tracking down your problem.

[Jeremy (jeremy-durge)]

Reproduced on Ubuntu with Firefox 2.0.0.6 - have previously submitted this as https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/134813 on the Ubuntu bug tracker system, and have put a reproduction example at http://wwwb.forbidden.co.uk/~jbj/firefoxbug.html

[Jeremy (jeremy-durge)]

Sorry for the delay. (This appears to be an upstream problem in any case - have also reproduced it in firefox/iceweasel V2 running on debian etch and debian lenny).

Packages:
flashplugin-nonfree version 9.0.48.0.0ubuntu1~7.04.1
sun-java5-jre version 1.5.0-11-1ubuntu2

Add-ons (Extensions):
Adblock 0.5.3.043 (and Filterset.G updater 0.3.1.0)
British English Dictionary 1.19
Fasterfox 2.0.0
Live HTTP Headers 0.13.1
Web Developer 1.1.4

[Jeremy (jeremy-durge)]

Reproduced with a new, blank Firefox profile.

[xtknight (xt-knight)]

I can reproduce this. Essentially, the context menu key on the keyboard needs to point to the exact (x, y) of the mouse's right click. Right now it is probably just using (0, 0) in the current control (which actually mirrors Windows' rather wrong behavior).

[xtknight (xt-knight)]

If you use nautilus, open a folder, then use the key on another application in the taskbar you'll see that this bug has nothing to do with Firefox, but instead GNOME.

[Vseerror (vseerror)]

immediately fails attachment (id=232021). if backout of bug 337368 didn't fix this, do we know if build of 2006-05-16-04 fails?

last word of comment 19 doesn't fail until removing the trailing space - but in that case the word isn't flagged as mispelled, so we shouldn't expect spell correction recommendations. This behavior is similar to bug 296366 IMO.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007110805 Minefield/3.0b2pre

[Vseerror (vseerror)]

improve summary

[Vseerror (vseerror)]

looks like dupe of bug 346930

[Csmiller (csmiller)]

When I try pressing Shift-F10 on a redlined word using

MS Windows XP, with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

on a multiline edit box that is several screenfulls down the page,
then the screen flickers like mad for a ~10 seconds.

It looks like the page is jumping repeatedly between the edit box and approx the middle of the screen.

The additional comment box at the bottom of the this page triggers it.

[Ruediger-lahl (ruediger-lahl)]

(In reply to comment #3)
> looks like dupe of bug 346930

No, I don't think so. 346930 is much older. This bug appeared first in January 07.
346930 is from August 06.

[private_lock (private-lock)]

within text NoWord within text

I could not trigger spell checking by Shift+F10 for the first error above, though it is working on right click. It seems on this system, the spell checking never recognizes a keyboard activation of the context menu.

I have no flicker as described in comment 23.

I cannot reproduce the vanishing red underline as in bug 296366.

System:
Kubuntu Gutsy Gibbon 7.10
uname -a
Linux samson 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/2.0.0.8
Dictionary en-US

[MrStonedOne (kyleshome)]

ok, i tested, it seems to be looking one line down:

Test line
dfjlkfsdalk
asdf

when cursor is on test i get "(no spelling suggestions)" when on dfjlkfsdalk i get "asked aside, etc" and i dont get any spelling suggestions on asdf

[MrStonedOne (kyleshome)]

(In reply to comment #25)
> ok, i tested, it seems to be looking one line down:
>
>
> Test line
> dfjlkfsdalk
> asdf
>
> when cursor is on test i get "(no spelling suggestions)" when on dfjlkfsdalk i
> get "asked aside, etc" and i dont get any spelling suggestions on asdf
>

above only applys to ff3b1. on ff2 (version info below), i cant get any to show with context menu, and cant seem to figure out any pattern

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20061201 Firefox/2.0.0.8 (Ubuntu-feisty)

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Nars (nars)]

I can reproduce this problem most of times (but not always) as well.

[Sgautherie-bz (sgautherie-bz)]

(In reply to comment #4)
> (In reply to comment #3)
> > looks like dupe of bug 346930

At least, the testcase there can be used to reproduce:

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008050906 Minefield/3.0pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008051002 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

> No, I don't think so. 346930 is much older. This bug appeared first in January
> 07.
> 346930 is from August 06.

Setting as "depends on" to investigate the SeaMonkey regression timeframe.
(Eventually, I "hope" to merge them as a (same) Core / Spelling checker bug.)

[Sgautherie-bz (sgautherie-bz)]

Created an attachment (id=320426)
testcase v1.1

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.15pre) Gecko/2008051103 BonEcho/2.0.0.15pre] (nightly) (W2Ksp4)

No (keyboard) suggestion, from either line :-(

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008050906 Minefield/3.0pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008051002 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Work from the line above. (see bug 370436)

[Sgautherie-bz (sgautherie-bz)]

Michaël, Jeremy,
see bug 346930 for (FF) 1.8.1 branch.

*****

(In reply to comment #0)
> Bug appears first in my SM-Trunk-builds from January the 18.

(In reply to comment #4)
> This bug appeared first in January 07.

Ruediger,
could you confirm any of these two dates ?

***

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070101 SeaMonkey/1.5a] (nightly, 2007-01-01-08-trunk) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070106 SeaMonkey/1.5a] (nightly, 2007-01-06-08-trunk) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070107 SeaMonkey/1.5a] (nightly, 2007-01-07-09-trunk) (W2Ksp4)

Afaict, all these three builds have this bug.
(I will test with older builds...)

[Sgautherie-bz (sgautherie-bz)]

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

[Sgautherie-bz (sgautherie-bz)]

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

[private_lock (private-lock)]

@Serge

I can confirm your testcase 1.1 with:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5

[Sgautherie-bz (sgautherie-bz)]

(In reply to comment #5)
> Setting as "depends on" to investigate the SeaMonkey regression timeframe.

It seems I misinterpreted the comments:
this is (a bug, but) not a regression.

(In reply to comment #6)
> (I will test with older builds...)

No spell checking:
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060501 SeaMonkey/1.5a] (nightly, 2006-05-01-15-trunk) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060616 SeaMonkey/1.5a] (nightly, 2006-06-16-11-trunk) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060708 SeaMonkey/1.5a] (nightly, 2006-07-08-10-trunk) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060720 SeaMonkey/1.5a] (nightly, 2006-07-20-10-trunk) (W2Ksp4)

Spell checking, but no (mouse) suggestion:
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060801 SeaMonkey/1.5a] (nightly, 2006-08-01-10-trunk) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060915 SeaMonkey/1.5a] (nightly, 2006-09-15-11-trunk) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060924 SeaMonkey/1.5a] (nightly, 2006-09-24-11-trunk) (W2Ksp4)

(enhancement) bug 338318 checkin !

(keyboard) One line off:
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060925 SeaMonkey/1.5a] (nightly, 2006-09-25-11-trunk) (W2Ksp4)

[Sgautherie-bz (sgautherie-bz)]

Firefox code came from bug 302050...

[Sgautherie-bz (sgautherie-bz)]

Maybe the one-line off is a follow-up to bug 337368, which activated the keyboard !?

[Beltzner (beltzner)]

If this isn't a regression from Firefox 2, then it's not going to be a hard blocker for Firefox 3, either. Definitely something to look into taking on the branch, though.

[Ruediger-lahl (ruediger-lahl)]

(In reply to comment #6)

> > Bug appears first in my SM-Trunk-builds from January the 18.
>
> > This bug appeared first in January 07.
>
> Ruediger,
> could you confirm any of these two dates ?

January the 18 definitely was in January 2007, so I can confirm both dates ;-)

> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070101
> SeaMonkey/1.5a] (nightly, 2007-01-01-08-trunk) (W2Ksp4)
> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070106
> SeaMonkey/1.5a] (nightly, 2007-01-06-08-trunk) (W2Ksp4)
> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070107
> SeaMonkey/1.5a] (nightly, 2007-01-07-09-trunk) (W2Ksp4)
>
> Afaict, all these three builds have this bug.
> (I will test with older builds...)

I cant find that old builds for the moment, so I can not check this out again. But I daily load a new SM-trunk-build, and when I wrote, that the bug first appears on January the 18', I had tested, that former builds don't had this bug on my system.

[Sgautherie-bz (sgautherie-bz)]

(In reply to comment #13)
> January the 18 definitely was in January 2007, so I can confirm both dates ;-)

Ah, sure: I read "07th" ;-<

> I cant find that old builds for the moment, so I can not check this out again.

<ftp.mozilla.org : /pub/seamonkey/nightly/>

> But I daily load a new SM-trunk-build, and when I wrote, that the bug first
> appears on January the 18', I had tested, that former builds don't had this bug
> on my system.

I didn't test 2007.01.17-18 builds; but my tests identify a much older date.
It would be interesting if you could test/confirm again.

[Ruediger-lahl (ruediger-lahl)]

(In reply to comment #14)

> <ftp.mozilla.org : /pub/seamonkey/nightly/>

Thanks, but this builds don't fit my updater-batch, since some files change their directions. Unfortunately the spell-dictionary is one of them :-(

If it's REALLY necessary, I can install it on Wednesday.

> > But I daily load a new SM-trunk-build, and when I wrote, that the bug first
> > appears on January the 18', I had tested, that former builds don't had this bug
> > on my system.
>
> I didn't test 2007.01.17-18 builds; but my tests identify a much older date.
> It would be interesting if you could test/confirm again.

As I wrote, I tested this builds in February 2007, before I filed the bug, to found out, that SM-Trunk-Builds before "January the 18'th" don't have this bug.

My suggestion is, that their are two bugs with nearly the same face.

As I wrote in https://bugzilla.mozilla.org/show_bug.cgi?id=370436#c4, MY bug first appears on January the 18'th 2007 and I never had https://bugzilla.mozilla.org/show_bug.cgi?id=346930 on my system.

[Sgautherie-bz (sgautherie-bz)]

(In reply to comment #30)

With a current FF build like this one, you should be seeing bug 370436, not this one.
Can you confirm which behavior you are seeing ?

[Sgautherie-bz (sgautherie-bz)]

(In reply to comment #15)
> If it's REALLY necessary, I can install it on Wednesday.
> As I wrote, I tested this builds in February 2007, before I filed the bug, to
> found out, that SM-Trunk-Builds before "January the 18'th" don't have this bug.

I think it could help if you could double check and report a precise timeframe (and possibly a bug "culprit").
(To compare with my comment 6 and comment 9.)

> My suggestion is, that their are two bugs with nearly the same face.

I agree: see my bug 346930 comment 29.
That is why I confirmed/differentiated this bug and not resolved it as duplicate of the other one.

[private_lock (private-lock)]

click
shift foopy

I followed your test instructions. No suggestion with cursor in "foopy" (even in this text box) and the suggestion appears when activated in "click". If applied it changes "foopy" to "loopy".

You're right, this is the bug 370436 I described. But since the test case is attached here...

It's quite stable behavior that the "spelling cursor" is one line below the real visible cursor. For now I could not get a suggestion for anything in the very first line. There is definitely a change to comment 19. I wonder if comment 24 was already bug 370436 instead but cannot check anymore.

[Ruediger-lahl (ruediger-lahl)]

(In reply to comment #16)

> I think it could help if you could double check and report a precise timeframe
> (and possibly a bug "culprit").

Okay, its done. SM 2007011809 WFM and SM 2007011909 shows the bug.
Tested with the 'Windows-zip-nightlys' from <ftp.mozilla.org : /pub/seamonkey/nightly/>
So the bug appears after 1809 and before 1909 in trunk.

I hope this window can help you to find out, which check-in cause the bug.

[Jruderman (jruderman)]

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

[Jruderman (jruderman)]

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

[Jruderman (jruderman)]

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

[Bugzilla-tangocharlie (bugzilla-tangocharlie)]

I have seen the issue inconsistently overall, but two place it ALWAYS happens are Yahoo! Mail compose screen, and in MySpace compose screens, such as for MySpace e-mail.

These are TEXTAREA fields, and always contained within FORM tags with a SUBMIT.

Hope this helps.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

[Claus-list (claus-list)]

This bug also concerns Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 I did not want to open a new bug report for that.
Tell me if I should.

HTH

[Luke Schlather (luke2760)]

Still here in 3.1a2pre on Ubuntu 8.04. I don't ever remember it working from the keyboard, though that may be just since I switched to Ubuntu a year ago. And I've used everything from ff2, to betas for 3, to 3.0, to 3.1a1. So this hasn't been in any way hit-or-miss as far as I'm concerned: it's a constant annoyance.

[Jruderman (jruderman)]

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

[Aaronleventhal (aaronleventhal)]

As Luke mentions in comment 37 this is a problem in all versions, not just 1.8.x.

It's been ignored until now because it did not appear to be a trunk bug.

Section 508 -- major issue.

[Marco-zehe (marco-zehe)]

Testing this with current nightly builds, I get inconsistent results:
1. if I misspell a word, don't hit SpaceBar after that, and go back, neither Shift+F10 nor pressing the Applications key will display a list of sufggestions. Note that I purposely chose a word like tessting that definitely yields results.
2. However, if I press Space after the misspelled word, then arrow back onto the word, both Shift+F10 and Applications bring up a list of suggested replacement words.

Aaron, if I misspell something and don't hit Space, is it then already marked as misspelled? The a11y attribute change for misspelling is not fired until hitting Space.

[Aaronleventhal (aaronleventhal)]

Hi Marco, for #1, the misspelled word was probably not marked misspelled yet. If you don't add whitespace or try right arrow at the end of the last word of a paragraph, it doesn't seem to get spellchecked at all. If you haven't gotten the a11y attribute change yet then it hasn't been marked on the screen either.

For #2, it's strange but I'm getting correct results now. But yesterday I definitely got the same results as Luke in comment 37, for this same build. I'll keep looking to see if I can reproduce.

For the record this is the build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081116 Minefield/3.1b2pre

[Aaronleventhal (aaronleventhal)]

Marco, I still see the bug. It seems to relate to what line of the textarea you are in (e.g. you have to be not on the first line). Try testcase 1.1 in this bug. I can reliably reproduce the issue described in that testcase.

[Marco-zehe (marco-zehe)]

I just tried this in this textarea, typing away a few lines and then mistyping something. I still can't reproduce. As soon as I hit space, then left arrow onto the misspelled word, then hit Applications, I get suggestions.

[Aaronleventhal (aaronleventhal)]

Marco, what about with the exact steps in testcase 1.1?

[Marco-zehe (marco-zehe)]

Yes, I see it in that testcase, and also if I make the sentence "The quick brown foxx jumped over the lazy dog." wrap to several lines so that "foxx" does not appear on the first line. If, however, I misspell "lazy" as "lazzy", and that's on the last line of the textarea, it will be OK. So it appears that the misspellings have to be there already, and have to appear not on the first and not on the last lines of a textarea, for this to fail.

[Beltzner (beltzner)]

Not going to block, but we'd take a safe, tested patch if nominated.

[Jruderman (jruderman)]

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

[Adam Buchbinder (adam-buchbinder)]

This is still present in Firefox 3.0.7; see bug 305251 (video included).

[John Vivirito (gnomefreak)]

will not be fixed in 2.0. changed to 3.0

[Umang Varma (umang)]

Platform should be changed to All since this bug affects Linux users also.
Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/134813

Also, I've noticed that this isn't 100% reproducible. Which makes it really weird. For example, right now (on bugzilla), I'm able to get the menu to work properly.

I copied from http://wwwb.forbidden.co.uk/~jbj/firefoxbug.html and pasted into this bugzilla textarea and it gives me Elephant while the cursor(?) is on Elefant. But when I go to http://wwwb.forbidden.co.uk/~jbj/firefoxbug.html itself, I am able to reproduce this bug (reproduce unwanted behavior).

So, change platform to All.
change reproducible to Not Always.

Thank you!

Umang

[Ruediger-lahl (ruediger-lahl)]

(In reply to comment #20)

> Platform should be changed to All since this bug affects Linux users also.

Done.

> Also, I've noticed that this isn't 100% reproducible.

Yes.

> I copied from http://wwwb.forbidden.co.uk/~jbj/firefoxbug.html and pasted into
> this bugzilla textarea and it gives me Elephant while the cursor(?) is on
> Elefant. But when I go to http://wwwb.forbidden.co.uk/~jbj/firefoxbug.html
> itself, I am able to reproduce this bug (reproduce unwanted behavior).

Funny, for me its directly opposed. :-)

> change reproducible to Not Always.

I Don't know how....

Thank you for testing.

[private_lock (private-lock)]

Right now, its quite stable reproducible ... I even shut down Firefox and reopened it:

In the textarea on http://wwwb.forbidden.co.uk/~jbj/firefoxbug.html I select all text, delete it and just type:

<ctrl>+<a><del>Dog<enter>
Elefant<cursor up><shift>+<F10>

Whereas, when I open this bugreport https://bugzilla.mozilla.org/show_bug.cgi?id=370436 and am logged in by cookie, I cannot reproduce the error in this textbox for comments.

Furthermore I have an add-on "Resizeable Textarea". But changing the aspect ratio or the presence of scrollbars does not affect this error.

To me, it seems as if at creation time the textbox decides, if it "wants" to be one row off. Thereafter any edit won't change it: any error on the second row goes to the contextmenue of the first row.

[Umang Varma (umang)]

Still an issue with Shiretoko (firefox-3.5 package from the Ubuntu Mozilla Security PPA). This is still very irritating....

Finally, even with Shiretoko, good behavior is seen on bugzilla and bad (unwanted/bug) behavior on http://wwwb.forbidden.co.uk/~jbj/firefoxbug.html

Umang

[Monfreda (monfreda)]

I get the same bug also in Thunderbird 3.0 beta 4. It happens always to me in Thunderbird, but not always in Firefox (3.5.4). Perhaps interesting tested for a few month Postbox, and had the same bug also in there.

Thanks
MaX

[Tor-klingberg-gmx (tor-klingberg-gmx)]

I can reproduce this in Firefox 3.5.4 on Ubuntu 9.10. It seems to choose spelling suggestions based on the position of the last right-click, rather than the current cursor position.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Ubuntu Bug:
https://bugs.launchpad.net/bugs/398330

[Dee-earlsoft (dee-earlsoft)]

This has also occured in all the TB3.0 builds, currently on beta 4

[Dee-earlsoft (dee-earlsoft)]

(on Windows)

[Philringnalda (philringnalda)]

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

[Philringnalda (philringnalda)]

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

[Kloor68373 (kloor68373)]

On TB3.0 it only occurs composing a text message, not in html mode.

[Dee-earlsoft (dee-earlsoft)]

I get this happening in text and HTML mode (once I found the option)
Right click works, context menu key doesn't.
This is now using TB3.0 (Gecko/20091130),

[fonji (fonji)]

I've got this problem using Firefox 3.5.5 Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5

[Rabarberski (rabarberski)]

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

[Rabarberski (rabarberski)]

(following my duplicate bug report, bug 535098)
For me this behavior does occur for English/United States spell check, but NOT when I am using Dutch spell check.

I am on Thunderbird 3 final (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0)

[Kloor68373 (kloor68373)]

This behaviour occures

using:
* Windows
* German Dictionary

situations:
* sometimes: Firefox 3.5.3
* always: composing text mails on Thunderbird 3.0
* never: composing html mails on Thunderbird 3.0

[Umang Varma (umang)]

Still affects me, Ubuntu Karmic Koala, Firefox 3.5.5

[Umang Varma (umang)]

This is really frustrating me. There seems to be no progress on this. Even Thunderbird 3.0 has this bug.

Can we have an update on whether this is being worked out?

[Hskupin (hskupin)]

(In reply to comment #17)
> Okay, its done. SM 2007011809 WFM and SM 2007011909 shows the bug.
> Tested with the 'Windows-zip-nightlys' from <ftp.mozilla.org :
> /pub/seamonkey/nightly/>
> So the bug appears after 1809 and before 1909 in trunk.

Ruediger, are you sure that this is the real time frame? I believe you have tested it inside the mail window, right? In your given time frame there is only one check-in which is related to the spell checker and this is bug 355064.

So I believe the underlying issue is inside the toolkit spell checker and has been broken earlier. Would you have time to test builds before that date?

[Cristian Klein (cristiklein)]

Hello,

I have been spending some time figuring out this issue and deduced the following. My opinion is that the "simulated right-click" happens a few pixels too low.

The events happen like this:

- The native back-end (e.g. GTK) is receiving a KeyPressEvent. If the "Context Menu" key is pressed, it will convert this into a nsMouseEvent, with coordinates (0,0) and the context type nsMouseEvent::eContextMenuKey (mozilla/widget/src/gtk2/nsWindow.cpp @ 3296)
- As the event propagates, nsEventListenerManager::FixContextMenuEvent() is called, which sets the coordinates to that of the caret, using PrepareToUseCaretPosition (mozilla/content/events/src/nsEventListenerManager.cpp @ 1422)

I doubt that the nsCaret's coordinates are wrong (else this might also create weird drawing artifacts), so I think the problem is related to how PrepareToUseCaretPosition processes this value.

I haven't got any more energy to study this, so it would be really cool if somebody could take over.

[Cristian Klein (cristiklein)]

Created an attachment (id=420730)
Ugly, but working proposed patch.

This patch has been tested against thunderbird-3.0 3.0.1~hg20091121r4400+nobinonly-0ubuntu1~umd1~karmic from
the PPA for Ubuntu Mozilla Daily Build Team.

[Cristian Klein (cristiklein)]

Hello everybody,

It seems I found the extra energy after all. :)

I attached a patch which moves the "simulated right-click" one pixel higher than before. I tested it against Thunderbird 3.0.1pre and it works.

I personally think the fix is ugly and the reason for the required hack should be further studied. However, seeing how many people are frustrated, it is a good temporary solution.

Could anybody see if this patch also works for FF? Thanks.

[Umang Varma (umang)]

Why only one pixel? It's off by one full line isn't it? How does it still work? Is this why this bug is not 100% reproducible?

(I hate it when I can only ask more questions without giving any answers..)

[Hskupin (hskupin)]

(In reply to comment #29)
> Created an attachment (id=420730) [details]
> Ugly, but working proposed patch.
>
> This patch has been tested against thunderbird-3.0
> 3.0.1~hg20091121r4400+nobinonly-0ubuntu1~umd1~karmic from
> the PPA for Ubuntu Mozilla Daily Build Team.

Neil, could you have a look at? Can we do that somehow this way?

[Neil-httl (neil-httl)]

mrbkap, is this covered by your caret experience?

[Cristian Klein (cristiklein)]

@Umang: Each text line has a bounding rectangle. It seems to me that FF / TB put the "simulated right-click" one pixel too low. Therefore, instead of "clicking" the lower edge of the expected text line, it click the upper edge of the text line underneath it.

I think I know the root of the problem. The caret position is stored in twips which are a much more precise unit that pixels. The PrepareToUseCaretPosition() first gets the lowest point of the caret (in twips) then converts it into pixels. This is done using round-to-nearest [1][2], which can return a pixel value outside the bounding rectangle of the expected text line.

This would also explain why the bug is not always hit. Different text sizes / scroll positions might determine rounding in the right direction.

I propose one of the following solutions:

1) Don't "click" on the lower edge of the caret. Click at say 80% or 90% of it.
2) Provide a round-down feature for AppUnitsToDevPixels.
3) (What my patch does) subtract 1, just to make sure.
4) Detect if round-up occurred (check if xInPixels * TwipsPerPixel == xInTwips) and compensate.

I could invest some time and implement these solutions, provided they would be accepted and included in the Mozilla Source Code.

[1] mozilla/mozilla/layout/base/nsPresContext.h @ 561
[2] mozilla/mozilla/gfx/public/nsCoord.h @ 330

[Cristian Klein (cristiklein)]

Created an attachment (id=420901)
Patch against HEAD which fixes this bug.

I attached a patch against HEAD to fix this bug.

Rationale: when a caret exists and the context menu is activated from the keyboard, FF simulates a right-click at the lowest coordinate of the caret. Since the caret's rectangle is stored in twips while mouse coordinates are in pixels, a conversion must happen between these two. AppUnitsToDevPixels does this using round-to-nearest, which however, might return a pixel which belong to the text line below the caret.

Instead of implementing a new conversion function which returns a round-down value, this patch offers a less intrusive solution. Rounding "compensation" takes place in the function that should be concerned with this, right after the conversion takes place.

Tested with Firefox (today's HEAD) on Ubuntu 9.10 with http://wwwb.forbidden.co.uk/~jbj/firefoxbug.html.

Could somebody please help me on how to get someone to review and check this in?

Thanks.

[Ruediger-lahl (ruediger-lahl)]

(In reply to comment #27)

> > So the bug appears after 1809 and before 1909 in trunk.
>
> Ruediger, are you sure that this is the real time frame?

Yes. Two times double checked.

[Roc-ocallahan (roc-ocallahan)]

(From update of attachment 420901)
you can't set review+, it hasn't been reviewed by someone appropriate

[Roc-ocallahan (roc-ocallahan)]

(From update of attachment 420901)
But I can. This makes complete sense. Thanks!!!

[Roc-ocallahan (roc-ocallahan)]

We need a mochitest for this using EventUtils.js and synthesizeMouse. However, we can check this in as-is.

[Reed Loden (reed)]

http://hg.mozilla.org/mozilla-central/rev/e3dd7678ff3f

[Umang Varma (umang)]

Well done! It took so long to find the bug, but in a couple of days of finding the problem you guys have fixed it. Thank you. This was probably the one bug that really irritated me. Can we expect this is 3.5.8?

[Cristian Klein (cristiklein)]

@roc: Sorry for setting review+, I thought it meant "needs reviewing". Thanks for checking the code so quickly. Also, thanks for giving me the hints on writing the mochitest. I will attach it soon.

@Umang: Since you are on Ubuntu, why don't you use Mozilla Daily PPA?

[Cristian Klein (cristiklein)]

Created an attachment (id=420945)
Mochitest for this bug.

This test contains a textarea with three lines of misspelled words. Using only synthesized keyboard events it tries to correct the word in the middle. At the end, it checks whether the content of the textarea is the expected one.

This test requires focus, or else, it won't even finish. :(

[Bugzilla-zirro (bugzilla-zirro)]

(In reply to comment #41)
> Well done! It took so long to find the bug, but in a couple of days of finding
> the problem you guys have fixed it. Thank you. This was probably the one bug
> that really irritated me. Can we expect this is 3.5.8?

This was checked in to the trunk, which currently is Firefox 3.7 Alpha 1. Is this important enough to be pushed to the 3.5 branch? Should this be checked in for 3.6, or should it start applying from Firefox 3.7 and onwards?

[Umang Varma (umang)]

@Cristian: I share the computer with not-so-tech-savy people also. They've "had problems" with beta earlier, like it was called "Shiretoko". But it's not like I'm in a hurry to get this. Not so much that I'll install dailies.

I guess Mozilla will have their own policy on what to include in which release. I'm not interfering. I'm psychologically satisfied that the fix has been committed, even if it will not be released very soon. Thank you for the fix, though. :)

[Monfreda (monfreda)]

Hi to all an thank you for the efforts. It looks like a solution is finally in sight. For me it is strange since it affects only Thunderbird (running 3.0) but not Firefox (running 3.5.7 right now).

I think it would be great if this fix could checked in to some previous Gecko (the one used in Thunderbird) as well.

Sorry if this is totally nontechnical, but i have no clue :-).. i am just a stupid user.

Max

[Bugzilla-zirro (bugzilla-zirro)]

There's no such thing as a stupid user, just very unexperienced ones (which you are not, as you've made it all the way to Bugzilla :) )

I am not sure about if this change risks breaking something, or if it relies on something that is only implemented in Firefox 3.6 and 3.7. The release of Firefox 3.6 is very close, which means two things.

1. As the release of 3.6 is so close, checking it in to 3.5 is a bit pointless.
2. As the release of 3.6 is so close, a fix like this might not be allowed to be checked in to 3.6 either as it might break features.

As it is not up to me what gets pushed, I'd like to ask those with the authority, is this going to be checked in for 1.9.2/3.6?

[Cristian Klein (cristiklein)]

I would offer to create similar patches against FF 3.5, FF 3.6, TB 3.0 and TB 3.1, if roc would be kind enough to review and check them in.

[Iann-bugzilla (iann-bugzilla)]

(In reply to comment #49)
> I would offer to create similar patches against FF 3.5, FF 3.6, TB 3.0 and TB
> 3.1, if roc would be kind enough to review and check them in.

TB shares parts of its code with FF, so only need to patch FF.
For those based on 1.9.2, the current patch probably just needs an approval request submitting as the code in 1.9.3 is very similar.
For those based on 1.9.1, the code is very different to 1.9.3, so, if the bug exists there, would need a new patch and review and approval.

[Bugzilla-zirro (bugzilla-zirro)]

Sounds like a lot of work to support on 1.9.1 then. My opinion is that checking it in for 1.9.2 is enough, which can't be more than a month away, even in a worst case scenario (right?).

[Roc-ocallahan (roc-ocallahan)]

(In reply to comment #44)
> Created an attachment (id=420945) [details]
> Mochitest for this bug.
>
> This test contains a textarea with three lines of misspelled words. Using only
> synthesized keyboard events it tries to correct the word in the middle. At the
> end, it checks whether the content of the textarea is the expected one.
>
> This test requires focus, or else, it won't even finish. :(

EventUtils has "waitForFocus" for that.

+ /* Correct "hellow" */
+ synthesizeMouse(ta, 0, 0, { type : "contextmenu" });
+ synthesizeKey("VK_DOWN", {})
+ synthesizeKey("VK_ENTER", {})

This is a bit of a problem, it will break if someone changes the layout of the context menu.

I think what you really care about here is the coordinates in the contextmenu event. I think the right thing to do is to check the clientX/clientY coordinates in the event. The tricky part is to make sure that your test fails without the patch, and passes with the patch.

+ /* Verify result */
+ synthesizeKey("VK_TAB", {})
+ synthesizeKey("VK_SPACE", {})

Instead of doing that, why not just call verifyResult directly?

[Bijumaillist (bijumaillist)]

There is already wanted1.9.0.x+ I thought it should take care.
Just in case it dont, I have requested a wanted1.9.2

[Cristian Klein (cristiklein)]

Created an attachment (id=421013)
Patch against 1.9.1.

This patch is functionally identical to the on against HEAD. The only difference is that the PrepareToUseCaretPosition() function moved from one file to the other.

[Cristian Klein (cristiklein)]

I just tested the patch I submitted against HEAD and it cleanly applied to 1.9.2.

@roc: Would you please be so kind and fix this bug in both 1.9.1 and 1.9.2, so that everybody is happy?

[Roc-ocallahan (roc-ocallahan)]

That's not actually my decision. Let's wait for branch drivers to respond to your approval request. Make sure this bug contains an explanation of why this bug is important enough to land on a stable branch. I can testify that the patch is low risk.

[Sgautherie-bz (sgautherie-bz)]

(From update of attachment 420945)
>diff -r 6a7294d0f305 content/events/test/Makefile.in
>@@ -77,16 +77,17 @@
> test_bug517851.html \
>+ test_bug370436.html \

Please, keep it sorted.

[Umang Varma (umang)]

Will this not reach 3.6, since the RC is already out?

[Bugzilla-zirro (bugzilla-zirro)]

There will be one more RC, but taking this in might be considered risky. It could come with 3.6.1 if it doesn't make 3.6RC2.

[Cristian Klein (cristiklein)]

(In reply to comment #52)
> (In reply to comment #44)
> > Created an attachment (id=420945) [details] [details]
> > Mochitest for this bug.
> >
> > This test contains a textarea with three lines of misspelled words. Using only
> > synthesized keyboard events it tries to correct the word in the middle. At the
> > end, it checks whether the content of the textarea is the expected one.
> >
> > This test requires focus, or else, it won't even finish. :(
>
> EventUtils has "waitForFocus" for that.
>
> + /* Correct "hellow" */
> + synthesizeMouse(ta, 0, 0, { type : "contextmenu" });
> + synthesizeKey("VK_DOWN", {})
> + synthesizeKey("VK_ENTER", {})
>
> This is a bit of a problem, it will break if someone changes the layout of the
> context menu.
>
> I think what you really care about here is the coordinates in the contextmenu
> event. I think the right thing to do is to check the clientX/clientY
> coordinates in the event. The tricky part is to make sure that your test fails
> without the patch, and passes with the patch.

Hello,

I think that what I really care about is the word on which the oncontextmenu occurred, as can be deduced from rangeParent and rangeOffset (this is what inlineSpellChecking uses). Unfortunately I have been unable to access this information. No matter what attribute I try to access on rangeParent, I get errors like:

Error: Permission denied to access property 'data' from a non-chrome context

Any pointers?

[Neil-httl (neil-httl)]

netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');

[Cristian Klein (cristiklein)]

(In reply to comment #61)
> netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');

Awesome. :)

[Cristian Klein (cristiklein)]

Created an attachment (id=421217)
Mochitest for this bug.

This test moves the cursor over a textarea and synthesizes a keyboard-style oncontextmenu. It then checks that the words returned by rangeParent are the correct ones.

Fails without the fix, succeeds with the fix.

[Roc-ocallahan (roc-ocallahan)]

We're getting close but not quite there yet :-)

+ var node = e.rangeParent;
+ var offset = e.rangeOffset;
+ words.push(node.data);

You're relying on the fact that the textarea breaks up each line into independent text nodes. That's not guaranteed, and in fact we're likely to change this soon. Here, you really should use 'offset' and check that the characters at 'offset' are the word you're expecting. Make sense?

[Cristian Klein (cristiklein)]

(In reply to comment #64)
> We're getting close but not quite there yet :-)
>
> + var node = e.rangeParent;
> + var offset = e.rangeOffset;
> + words.push(node.data);
>
> You're relying on the fact that the textarea breaks up each line into
> independent text nodes. That's not guaranteed, and in fact we're likely to
> change this soon. Here, you really should use 'offset' and check that the
> characters at 'offset' are the word you're expecting. Make sense?

Yes. Deep down inside I was afraid you might say that. :)

[Cristian Klein (cristiklein)]

Created an attachment (id=421240)
Mochitest for this bug.

[Roc-ocallahan (roc-ocallahan)]

(From update of attachment 421240)
OK, but you can vastly simplify the code by using a better regular expression. E.g.:

<script>
function offsetToWord(data, offset) {
  var rest = data.substr(offset);
  var m = rest.match(/^\w+/);
  return m ? m : "";
}
function test(data, offset) {
  document.write("offsetToWord(\"" + data + "\"," + offset + ") = \"" + offsetToWord(data, offset) + "\"<br>");
}
test("hello kitty", 0);
test("hello kitty", 2);
test("hello kitty", 5);
test("hello kitty", 6);
test("hello kitty", 8);
</script>

Please revise the patch like that and then we can get this landed.

[Cristian Klein (cristiklein)]

(In reply to comment #67)
Hello,

The code you wrote does not exactly do what I intended. More precisely, it does not extend the range to the left, so as to include the whole word. I would expect offsetToWord('hello kitty', 2) to return 'hello'.

I intended my code like this, because in future I might want to test whether the contextmenu works correctly in the middle of the word or between words ('hello| world' + contextmenu should return 'hello' and not 'world').

However, for the current bug, the mochitest might seem a little over-engineered. Do you still think I should simplify the code?

[Roc-ocallahan (roc-ocallahan)]

OK then, just use this:

function offsetToWord(data, offset) {
  var m1 = data.substr(0, offset).match(/\w+$/) || "";
  var m2 = data.substr(offset).match(/^\w+/) || "";
  return m1 + m2;
}

[Neil-httl (neil-httl)]

(In reply to comment #69)
> function offsetToWord(data, offset) {
> var m1 = data.substr(0, offset).match(/\w+$/) || "";
> var m2 = data.substr(offset).match(/^\w+/) || "";
Unfortunately all of the regexp methods return an array of matches (including any parenthetical captures) rather than the matching string itself. You could however use \w* instead of \w+ to force a match to exist, e.g.
var m1 = data.substr(0, offset).match(/\w*$/)[0];

[Cristian Klein (cristiklein)]

Created an attachment (id=421424)
Mochitest for this bug.

Nice way of selecting the closest word.

BTW, while writing the test case I observed that there is another bug in FF. Opening the context menu at the end of the line returns rangeParent.data "undefined". Since this is out of the scope of the current bug and since it isn't as annoying, I did not include tests for it in the mochitest.

[Roc-ocallahan (roc-ocallahan)]

Looks good, but one more thing! You should use SimpleTest.waitForFocus to start the test.

(In reply to comment #71)
> BTW, while writing the test case I observed that there is another bug in FF.
> Opening the context menu at the end of the line returns rangeParent.data
> "undefined". Since this is out of the scope of the current bug and since it
> isn't as annoying, I did not include tests for it in the mochitest.

I suspect this is not actually a bug. I suspect the rangeParent is a <br> element. This probably isn't a good thing to return, but it doesn't matter too much since the details of what a textarea contains are not visible to Web content.

Thanks!

[Cristian Klein (cristiklein)]

Created an attachment (id=421517)
Mochitest for this bug.

With waitForFocus()

[Umang Varma (umang)]

I don't know too much about all this so don't even take my comments as suggestions - just take them as questions.

Why does Firefox chose the bottom most pixel to right click on? When I right click a word to get suggestions by spell check, I click in the middle of the character. So shouldn't you actually subtract 50% of the line height or the text size (I really don't know which one I mean) from the bottom most pixel? I guess -1 pixel is also fine, because no one will type with a font size of 1 pixel and we will almost never jump _up_ a line, but -(0.5*line-height) would make more sense to me. What's the reasoning behind using the bottom of the Caret rather than the middle?

[Cristian Klein (cristiklein)]

(In reply to comment #74)
> What's the reasoning behind using the bottom of the
> Caret rather than the middle?

I suppose the original designer had UI usability in mind. If the context menu opens downwards and its origin is at the bottom of the caret, you can still see the whole word / line to which the context menu applies. If, for example, you misspelled a word, you might want to re-read that line with one of the suggestions, to make sure it is the right one.

Of course, it would be totally cool if the top of the caret was taken as the origin when the context menu opens upwards. :D

[Roc-ocallahan (roc-ocallahan)]

(In reply to comment #75)
> I suppose the original designer had UI usability in mind. If the context menu
> opens downwards and its origin is at the bottom of the caret, you can still see
> the whole word / line to which the context menu applies. If, for example, you
> misspelled a word, you might want to re-read that line with one of the
> suggestions, to make sure it is the right one.

Yeah, absolutely.

> Of course, it would be totally cool if the top of the caret was taken as the
> origin when the context menu opens upwards. :D

Our popup menus do have support for an "anchor rect" which will do this. Patches accepted :-).

[Umang Varma (umang)]

Well that problem too isn't really solved properly, because if you scroll up a little, so that this textarea is at the bottom of your screen and the open the context menu, the menu pops up from the bottom of the text and covers the word anyway. Textareas like these also tend to be at the bottom of the page, so that logic (that the word shouldn't get covered) is still not implemented properly. But yes, a popup menu that actually pops up and not down would be awesome!

[Philneary (philneary)]

I know this has been pretty much rapped up now, but I have found that increasing the text by a size on the pages that give trouble, will get things working as they should. I have Firefox set to "only zoom text" I'm not sure if this makes a difference. Also you can do this while typing, say, if this was one of the areas of text that wasn't working properly and suggestions were not being brought up with the menu key. Then I could increase the font by a size to get it to work and without having to navigate away from the page or restart Firefox. If you change the font back to a size smaller, it will stop working again.

It's not ideal, but it works, and we have a proper fix for this already. I just thought I'd mention it as a temporary solution for those of us who are eagerly waiting the proper fix.

[Dveditz (dveditz)]

(From update of attachment 421013)
Not approved for the older security branches (1.9.1.8-minus specifically), this does not meet the branch criteria.

[Umang Varma (umang)]

Will this reach 3.6.1?

[Hskupin (hskupin)]

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

[Pauljagnew (pauljagnew)]

Crashes out of MINEFIELD when you envoke the inline spellchecker. (Windows 7, 64bit)

[Beltzner (beltzner)]

(From update of attachment 420901)
a1922=beltzner, please land this and the mochitest

[Sgautherie-bz (sgautherie-bz)]

(From update of attachment 421517)

http://hg.mozilla.org/mozilla-central/rev/d50a6e09b8d0

[Sgautherie-bz (sgautherie-bz)]

(In reply to comment #82)
> http://hg.mozilla.org/mozilla-central/rev/d50a6e09b8d0

{
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1267621810.1267624217.16711.gz&fulltext=1
WINNT 5.2 mozilla-central opt test mochitests-4/5 on 2010/03/03 05:10:10

7 times:
... INFO TEST-PASS | .../test_bug370436.html | undefined
}

Something is wrong, no?

[Mak77 (mak77)]

these should either be ok(), or have a message.

    2.70 + is(words.pop(), "welcome");
    2.71 + is(words.pop(), "world");
    2.72 + is(words.pop(), "hello");
    2.73 + is(words.pop(), "hello");
    2.74 + is(words.pop(), "sheep");
    2.75 + is(words.pop(), "sheep");
    2.76 + is(words.pop(), "sheep");

[Timeless-bemail (timeless-bemail)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/f4c287243458

i skipped the mochitest because the chatter in comment 83 / comment 84 is scary

[Umang Varma (umang)]

Thank you! Wow, three years and one month!

(This might make 3.6.2 one of the most exciting releases for me, this bug has irritated me for a long time). I guess it will take a while before it is fixed in TB right? (Guessing from https://developer.mozilla.org/en/Gecko)

[Gavin Sharp (gavin-sharp)]

(In reply to comment #85)
> i skipped the mochitest because the chatter in comment 83 / comment 84 is scary

We should fix comment 84 (by adding comments), but it shouldn't block landing the test on the branch.

[Cristian Klein (cristiklein)]

Created an attachment (id=431693)
Mochitest for this bug.

Added needed parameters.

[Mak77 (mak77)]

test pushed on 1.9.2: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c943463925b3
i'll sync test on central now.

[Mak77 (mak77)]

synced test: http://hg.mozilla.org/mozilla-central/rev/8dc56c4c00b9

[Marco-zehe (marco-zehe)]

Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. I noticed that the version of Ubuntu your using is in End of Life status. More information may be found at: https://wiki.ubuntu.com/Releases As well, Firefox is updated in Maverick. Please update via www.ubuntu.com repost a detailed error report, and update the bug status. Thanks!

[Adam Buchbinder (adam-buchbinder)]

This is fixed as of Firefox 3.6.8 on Karmic.