Closed Bug 346930 Opened 18 years ago Closed 10 years ago

Spelling suggestions don't appear in context menu when its invoked via the keyboard: Shift+F10 and context menu key

Categories

(Core :: Spelling checker, defect)

Product:
Core
Component:
Spelling checker
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ispiked, Unassigned)

References

Details

(Keywords: access, qawanted, regression)

Attachments

(1 file, 1 obsolete file)

testcase v1.1
693 bytes, text/html
Details
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b1) Gecko/20060801 BonEcho/2.0b1 This has regressed since bug 337368 got fixed. Steps to reproduce: 1. In a bugzilla comment field type "spellin". 2. Make sure your cursor is in the word somewhere and hit Shift+F10. Results: Context menu appears but doesn't have spelling suggestions in it. Expected results: Context menu has spelling suggestions.
Seems to work for me on my Linux branch build.
I can reproduce in a tinderbox build and my own branch build from this morning. I created a new profile just to test this.
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.
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060731 BonEcho/2.0b1
Backing out the patch for bug 337368 did not fix this for me.
Keywords: qawanted
Confirming previous comments that this does not affect Windows builds (tested 2006-08-02 branch).
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).
OS: Linux → All
Hardware: PC → All
Attached file testcase (obsolete) —
I can reliably reproduce this bug on Windows trunk using this testcase.
(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.
(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.
*** Bug 355328 has been marked as a duplicate of this bug. ***
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.
*** Bug 358337 has been marked as a duplicate of this bug. ***
(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 !
*** Bug 358982 has been marked as a duplicate of this bug. ***
Assignee: nobody → brettw
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.
Assignee: brettw → nobody
Severity: normal → major
Priority: -- → P1
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.
Attachment #232021 - Attachment mime type: text/html → text/html, UTF-16
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".
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
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
improve summary
Summary: Spelling suggestions don't appear in context menu when its invoked via the keyboard → Spelling suggestions don't appear in context menu when its invoked via the keyboard: Shift+F10 and context menu key
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.
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
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
(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)
I can reproduce this problem most of times (but not always) as well.
Attached file 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)
Attachment #232021 - Attachment is obsolete: true
No longer blocks: 370436
Depends on: 370436
Assignee: nobody → mscott
Component: Menus → Spelling checker
Priority: P1 → --
Product: Firefox → Core
QA Contact: menus → spelling-checker
Summary: Spelling suggestions don't appear in context menu when its invoked via the keyboard: Shift+F10 and context menu key → [1.8.1 branch] Spelling suggestions don't appear in context menu when its invoked via the keyboard: Shift+F10 and context menu key
Version: 2.0 Branch → 1.8 Branch
@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
(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 ?
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.
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
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
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.
Assignee: mscott → nobody
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.
Flags: blocking1.9.1?
Keywords: sec508
Summary: [1.8.1 branch] Spelling suggestions don't appear in context menu when its invoked via the keyboard: Shift+F10 and context menu key → Spelling suggestions don't appear in context menu when its invoked via the keyboard: Shift+F10 and context menu key
Version: 1.8 Branch → Trunk
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.
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
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.
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.
Marco, what about with the exact steps in testcase 1.1?
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.
Not going to block, but we'd take a safe, tested patch if nominated.
Flags: blocking1.9.1? → blocking1.9.1-
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.
This has also occured in all the TB3.0 builds, currently on beta 4
(on Windows)
On TB3.0 it only occurs composing a text message, not in html mode.
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),
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
(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)
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
Crashes out of MINEFIELD when you envoke the inline spellchecker. (Windows 7, 64bit)
Please FIX this bug in the next Release of Thunderbird! I cannot understand why it has not been fixed. This bug has many dups and is apparently present since 2006. That's been 4 years, guys. If I am missing something, please explain to us why this bug has not been fixed to date. It is a very annoying when you use the keyboard only to compose a message! Still present in: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
Can someone still reproduce this bug after bug 370436 has landed on Firefox 3.6.2? Note that this is currently expected to show up in Thunderbird, but I'd be interested if those reporting it can still repro it in Firefox 3.6.3.
Seems to be fixed on my Firefox 3.6.3 on Win XP SP3. "Seems" because of the bug's infrequent character.
musterstudent and other thunderbird users, this fix will be in v3.1, and doesn't qualify for landing in v3.0 WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.2pre) Gecko/20100405 Lanikai/3.1b2pre
(In reply to comment #63) > Seems to be fixed on my Firefox 3.6.3 on Win XP SP3. "Seems" because of the > bug's infrequent character. Hi guys. I've reported this bug years ago and it also seems to be fixed on my Firefox 3.6.3 (I'm currently running Windows Vista 64 bits SP2). Good job :)
See comment#65. Seems to have been fixed by bug 370436. Closing WFM. Please reopen if you encounter problems in this area again. Note that this does NOT count for Thunderbird 3.0 yet, but will for Thunderbird 3.1.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
This problem doesn;t exist in the current lanikai either
Please reopen this bug (I cannot). This problem exists in the latest stable release of Firefox (version 31).
first type a long line until the text automatically wraps. type a long line type a long line type a long line. now start a new paragraph write tessting with a surplus s shift+F10 will not work, though right click reveals a nice list of suggestions. Reproduced in the comment box below with FF31 on Kubuntu 14.04 64-bit @Huji you're quite right! But I simply gave up on using the keyboard for this.
Reopened based on comment 68 and 69. I can't test it myself, this moment, because I'm on MacOS X now, see bug 801812.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The 40+ people previously cc on this bug deemed the problem that existed 4 years go to be gone. Plus, new issues really deserve new bugs. So reclosing. Please file a new bug if an *open* one with a matching description does not already exist.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: