After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 777086 - Composer sometimes hangs on right-click above a word in the body
Composer sometimes hangs on right-click above a word in the body
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Composer
3.22.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Tomas Popela
Evolution QA team
: 775274 785472 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-01-10 13:00 UTC by Phil Wyett
Modified: 2017-08-10 00:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Video example. (197.88 KB, video/webm)
2017-01-10 13:00 UTC, Phil Wyett
Details
View of error - Antergos x86_64 (93.99 KB, image/png)
2017-01-12 06:19 UTC, Phil Wyett
Details

Description Phil Wyett 2017-01-10 13:00:10 UTC
Created attachment 343241 [details]
Video example.

Spell check hangs when right click over a word until you move out of window bounds.

Evolution: 3.22.3

OS: Aantergos (arch based)

How to reproduce.

* Enable spell check as you type.
* Create new email.
* Type in three words that are misspelled. My case 'color', 'mett', 'darwen'.
* Left click into the text of one of the words, then right click.

Spell check context menu will appear.

* Right click on a mispelled word that does not have the cursor within it.

Spell check context menu will not appear (hang) until you move your mouse outside the composer window.
Comment 1 Milan Crha 2017-01-10 18:44:12 UTC
Thanks for a bug report. I could reproduce it too, but for me it was rather about the below error message being printed on the evolution's console, than about moving cursor away from the composer window.

> (evolution:13987): evolution-util-WARNING **: Failed to call a DBus Proxy
> method org.gnome.Evolution.WebExtension.EWebKitEditor.WC0x3909f00::DOMGetCaretWord:
> Timeout was reached

I was able to reproduce it only when the CPU was busy with some other tasks, though, thus it's higly about the timing. I caught the backtrace of the evolution:

Thread 1 (Thread 0x7f2c6d322fc0 (LWP 13987))

  • #0 poll
  • #1 g_main_context_poll
    at gmain.c line 4228
  • #2 g_main_context_iterate
    at gmain.c line 3924
  • #3 g_main_context_iteration
    at gmain.c line 3990
  • #4 e_util_invoke_g_dbus_proxy_call_sync_wrapper_full
    at ..../evolution/src/e-util/e-misc-utils.c line 3815
  • #5 e_util_invoke_g_dbus_proxy_call_sync_wrapper_with_error_check
    at ..../evolution/src/e-util/e-misc-utils.c line 3744
  • #6 webkit_editor_get_caret_word
    at ..../evolution/src/modules/webkit-editor/e-webkit-editor.c line 2226
  • #7 e_content_editor_get_caret_word
    at ..../evolution/src/e-util/e-content-editor.c line 1597
  • #8 html_editor_update_actions
    at ..../evolution/src/e-util/e-html-editor.c line 425
  • #9 g_closure_invoke
    at gclosure.c line 804
  • #10 signal_emit_unlocked_R
    at gsignal.c line 3673
  • #11 g_signal_emit_valist
    at gsignal.c line 3391
  • #12 <emit signal ??? on instance 0x3cc2bc0 [EHTMLEditor]>
    at gsignal.c line 3447
  • #13 html_editor_context_menu_requested_cb
    at ..../evolution/src/e-util/e-html-editor.c line 503
  • #14 ffi_call_unix64
  • #15 ffi_call
  • #20 <emit signal ??? on instance 0x46cab70 [EWebKitEditor]>
    at gsignal.c line 3447
  • #16 g_cclosure_marshal_generic
    at gclosure.c line 1490
  • #17 g_closure_invoke
    at gclosure.c line 804
  • #18 signal_emit_unlocked_R
    at gsignal.c line 3635
  • #19 g_signal_emit_valist
    at gsignal.c line 3401
  • #21 e_content_editor_emit_context_menu_requested
    at ..../evolution/src/e-util/e-content-editor.c line 3560
  • #22 webkit_editor_context_menu_cb
    at ..../evolution/src/modules/webkit-editor/e-webkit-editor.c line 5769
  • #23 webkit_marshal_BOOLEAN__OBJECT_BOXED_OBJECT
  • #27 <emit signal ??? on instance 0x46cab70 [EWebKitEditor]>
    at gsignal.c line 3447
  • #24 g_closure_invoke
    at gclosure.c line 804
  • #25 signal_emit_unlocked_R
    at gsignal.c line 3635
  • #26 g_signal_emit_valist
    at gsignal.c line 3401
  • #28 webkitWebViewPopulateContextMenu(_WebKitWebView*, WTF::Vector<WebKit::WebContextMenuItemData, 0ul, WTF::CrashOnOverflow, 16ul> const&, WebKit::WebHitTestResultData const&, _GVariant*)
  • #29 ContextMenuClient::getContextMenuFromProposedMenu(WebKit::WebPageProxy&, WTF::Vector<WTF::RefPtr<WebKit::WebContextMenuItem>, 0ul, WTF::CrashOnOverflow, 16ul> const&, WTF::Vector<WTF::RefPtr<WebKit::WebContextMenuItem>, 0ul, WTF::CrashOnOverflow, 16ul>&, WebKit::WebHitTestResultData const&, API::Object*)
  • #30 WebKit::WebContextMenuProxyGtk::show()
  • #31 WebKit::WebPageProxy::internalShowContextMenu(WebKit::ContextMenuContextData const&, WebKit::UserData const&)
  • #32 WebKit::WebPageProxy::showContextMenu(WebKit::ContextMenuContextData const&, WebKit::UserData const&)
  • #33 void IPC::handleMessage<Messages::WebPageProxy::ShowContextMenu, WebKit::WebPageProxy, void
  • #34 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
  • #35 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&)
  • #36 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
  • #37 IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >)
  • #38 IPC::Connection::dispatchOneMessage()
  • #39 WTF::RunLoop::performWork()
  • #40 WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*)
  • #41 g_main_dispatch
    at gmain.c line 3203
  • #42 g_main_context_dispatch
    at gmain.c line 3856
  • #43 g_main_context_iterate
    at gmain.c line 3929
  • #44 g_main_loop_run
    at gmain.c line 4125
  • #45 gtk_main
    at gtkmain.c line 1301
  • #46 main
    at ..../evolution/src/shell/main.c line 667

Comment 2 Milan Crha 2017-01-10 18:46:03 UTC
Err, there is some information in the middle of the backtrace above, with another backtrace. 

Could you verify, whether it's the same for you, thus that the issue is about the timeout being reached when the DOMGetCaretWord had been issued on the evolution side, which is printed on the evolution console, when you run it from a terminal, please?
Comment 3 Phil Wyett 2017-01-10 23:30:01 UTC
Can you detail the debug procedure?
Comment 4 Milan Crha 2017-01-11 10:28:11 UTC
Just run evolution from a terminal and open the message composer. Reproduce the issue and once the popup menu shows up, switch to the terminal window and see whether any new messages were shown there. A one like this one:

> (evolution:13987): evolution-util-WARNING **: Failed to call a DBus Proxy
> method org.gnome.Evolution.WebExtension.EWebKitEditor.WC0x3909f00::DOMGetCaretWord:
> Timeout was reached

means that you are facing the same issue.
Comment 5 Phil Wyett 2017-01-12 06:19:11 UTC
Created attachment 343345 [details]
View of error - Antergos x86_64
Comment 6 Phil Wyett 2017-01-12 06:20:55 UTC
Managed to recreate the error message you referred to and get output in terminal under higher load (copying an ISO to another folder on disk). See screenshot.
Comment 7 Milan Crha 2017-01-12 14:53:08 UTC
Thanks for the update. In that case I'd say it's the same thing, caused by the timing issue. I've no idea how to address it, though, because the menu cannot be shown and then updated without side-effects (misposition or a wrong size being used).
Comment 8 Milan Crha 2017-01-18 08:22:50 UTC
*** Bug 775274 has been marked as a duplicate of this bug. ***
Comment 9 Milan Crha 2017-07-27 15:40:42 UTC
I tried to postpone the whole invocation of the context menu and it seems to work. What I did think of before was to postpone the invocation of the update-actions signal only.

Created commit fbd907e in evo master (3.25.90+)
Created commit 111095e in evo gnome-3-24 (3.24.5+)
Comment 10 Jonathan 2017-07-27 18:28:42 UTC
*** Bug 785472 has been marked as a duplicate of this bug. ***