OLD | NEW |
(Empty) | |
| 1 # High Level |
| 2 |
| 3 There will be a context menu from which the display of the spelling panel can be
toggled. This will tie into some methods in webkit that will make sure that the
selection is in the right place and in sync with the panel. By catching the mes
sages that the spelling panel sends we can also do the right things when the use
r asks to correct words, ignore words, move to the next misspelled word and lear
n words. Additionally, the language of the spellchecker can also be changed thro
ugh the spelling panel. |
| 4 |
| 5 # Details |
| 6 |
| 7 ## Toggling the Spelling Panel |
| 8 |
| 9 Design document for the addition of the spelling panel to Chromium |
| 10 |
| 11 * Add a new define, `IDC_SPELLING_PANEL_TOGGLE`, to chrome\_dll\_resource.h. |
| 12 * Add code to `RenderViewContextMenu::AppendEditableItems` to check the state
of the spelling panel and make the right decision. Note that this has to touch t
he function `SpellCheckerPlatform::SpellingPanelVisible()` which should only be
called from the main thread (which this is, so it's ok). |
| 13 * Showing the spelling panel works as follows: `RenderViewContextMenu::Execute
Command` will need another case to handle the added define. It calls `source_tab
_contents_->render_view_host()->ToggleSpellPanel()`, which in turn does `Send(ne
w ViewMsg_ToggleSpellPanel(routing_id(),bool))`. The bool should be the current
state of the spelling panel, which is cached on the webkit side to avoid an extr
a IPC call that would be difficult to execute, due to the limitations with `Spel
lCheckerPlatform::SpellingPanelVisible()`. This message is caught in `RenderView
`, which caches the visibility and then calls `ToggleSpellPanel` on the focused
frame. This call ends up at `WebFrameImpl`, which forwards the call to the webki
t method `Editor::showSpellingGuessPanel`. From here, webkit does a few things a
nd then calls `advanceToNextMispelling`, which calls `client()->updateSpelling
UIWithMisspelledWord(misspelledWord);` which will eventually end up back in the
browser due to an IPC call. We can update the panel using `[[NSSpellChecker shar
edSpellChecker] updateSpellingPanelWithMisspelledWord:nextMisspelledWord]`. Afte
r that, `client()->showSpellingUI(true)` is called. This puts us back in the web
kit glue code in editor\_client\_impl.cc. From here, we grab the current `WebVie
wDelegate` and call `ShowSpellingUI`. This call ends up in `RenderView`, since i
t implements `WebViewDelegate`, which finally does `Send(new ViewHostMsg_ShowSpe
llingPanel(routing_id_,show)`). This is caught in `resource_message_filter.cc`,
which forwards the call to `SpellCheckerPlatform::ShowSpellingPanel` where we fi
nally display the panel. Hiding the spelling Panel is a similar processs (i.e. w
e go through webkit and eventually receive a message back telling us to hid the
spelling panel). |
| 14 |
| 15 ## Spellchecking Words |
| 16 * `advanceToNextMisspelling` in webkit ensures that the currently misspelled w
ord is selected. When the user clicks on the change button in the spelling corre
ction panel, the panel sends a message up the responder chain. We catch this mes
sage (`changeSpelling`) in `render_widget_host_view_mac.mm` and interrogate the
spelling panel (the sender) to find out what the new word is. We then send an IP
C message to the renderer telling it to replace the selected word and advance to
the next misspelling, the machinery for which already exists in webkit. The spe
lling panel will also send the `checkSpelling` message, although this is not ver
y well documented. Anytime we receive this message, we should advance to the nex
t misspelled word, which we can do using `advanceToNextMisspelling`. |
| 17 |
| 18 ## The Find Next Button |
| 19 * When the Find Next button is clicked, the spelling panel sends just the `che
ckSpelling` message, so little additional work is needed to enable Find Next. |
| 20 |
| 21 ## Learning Words |
| 22 * When the Learn Button is clicked, the spelling panel handles telling OS X to
learn the word, but we still need to move to the next word and provide it with
the next misspelling. Again, this is just a matter of catching the `checkSpellin
g` message. |
| 23 |
| 24 ## Ignoring Words |
| 25 * In order to support ignoring words, we need to have unique document tags for
every RenderView; this could be done at a more fine grain level, but this is ho
w mainline webkit does it. Whenever a spellcheck request is generated in webkit,
it asks for a document tag, which we can obtain from the browser through an IPC
call (the actual tags are generated by `[NSSpellChecker uniqueSpellDocumentTag]
`). This tag is stored in the RenderView and all spellchecking requests from web
kit now bundle the tag. On platforms other than OS X, it is eventually ignored. |
| 26 * When the user clicks the Ignore button in the panel, we receive an `ignoreSp
elling` message. We send this to `SpellCheckerPlatform::IgnoreWord`, where we ca
n make the calls to the NSSpellChecker to ignore the word. However, there is a p
roblem. We don't know what the tag of the document that we are in is. To solve t
his, we cache the document tag whenever we spellcheck a word and use that docume
nt tag. |
| 27 * When a RenderView is closed, it sends an IPC message to the Browser telling
it that the document with it's tag has been closed. This lets us forget those wo
rds that we no longer need to ignore. |
| 28 |
| 29 ## Unresolved Issues |
| 30 * The spelling panel displays `Multilingual` as an option for the spelling lan
guage, which is not currently supported by chromium. |
OLD | NEW |