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 704271 - Evolution hangs on rendering a message
Evolution hangs on rendering a message
Status: RESOLVED NOTGNOME
Product: evolution
Classification: Applications
Component: Mailer
3.10.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 711616 725724 729301 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-07-15 16:38 UTC by Kjartan Maraas
Modified: 2015-04-21 08:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Kjartan Maraas 2013-07-15 16:38:00 UTC 
(gdb) bt full

+ Trace 232245

  • #0 isAnonymousBlock
    at Source/WebCore/rendering/RenderObject.h line 510
  • #1 WebCore::AccessibilityObject::accessibilityPlatformIncludesObject
    at Source/WebCore/accessibility/atk/AccessibilityObjectAtk.cpp line 96
  • #2 WebCore::AccessibilityRenderObject::accessibilityIsIgnoredBase
    at Source/WebCore/accessibility/AccessibilityRenderObject.cpp line 1116
  • #3 WebCore::AccessibilityRenderObject::computeAccessibilityIsIgnored
    at Source/WebCore/accessibility/AccessibilityRenderObject.cpp line 1134
  • #4 WebCore::AXObjectCache::notificationPostTimerFired
    at Source/WebCore/accessibility/AXObjectCache.cpp line 647
  • #5 WebCore::ThreadTimers::sharedTimerFiredInternal
    at Source/WebCore/platform/ThreadTimers.cpp line 129
  • #6 WebCore::timeout_cb
    at Source/WebCore/platform/gtk/SharedTimerGtk.cpp line 49
  • #7 g_timeout_dispatch
    at gmain.c line 4413
  • #8 g_main_dispatch
    at gmain.c line 3054
  • #9 g_main_context_dispatch
    at gmain.c line 3630
  • #10 g_main_context_iterate
    at gmain.c line 3701
  • #11 g_main_loop_run
    at gmain.c line 3895
  • #12 gtk_main
    at gtkmain.c line 1156
  • #13 main
    at main.c line 707 






Comment 1


Kjartan Maraas





          2013-07-15 19:14:23 UTC
        



This problem went away when I enabled the toolkit-accessibility key under org.gnome.desktop.interface strangely enough. Maybe webcore doesn't handle this being disabled correctly?






Comment 2


Matthew Barnes





          2013-07-15 19:22:52 UTC
        



Might want to move this over to https://bugs.webkit.org/ then for the WebKit/GTK+ dudes to handle.

Closing this NOTGNOME since it's out of scope for Evolution.






Comment 3


Milan Crha





          2014-03-06 09:55:57 UTC
        



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






Comment 4


Milan Crha





          2014-03-06 16:35:31 UTC
        



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






Comment 5


Milan Crha





          2014-07-10 13:58:14 UTC
        



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






Comment 6


Milan Crha





          2014-07-10 14:00:20 UTC
        



Tomas, do we have any webkit bug report for this issue, please? Would it help if a reproducer HTML page would be offered to webkit folks?






Comment 7


EMR_Gnome





          2014-07-11 16:20:02 UTC
        



Please note that the problem I have been having was a 10MB plain text cron email. There is no HTML in the message.






Comment 8


Milan Crha





          2014-07-14 09:00:07 UTC
        



(In reply to comment #7)
> Please note that the problem I have been having was a 10MB plain text cron
> email. There is no HTML in the message.

Sure, the plain text email is transformed to an HTML and then passed to webkit to be rendered in a preview panel.






Comment 9


David Juran





          2014-08-20 11:19:06 UTC
        



Was there ever a webkit bug created for this? Do we have a reference?






Comment 10


Brian J. Murrell





          2014-09-08 12:16:02 UTC
        



I think I'm experiencing this also:





+
Trace
    234071






Thread 1
          (Thread 0x7f974c8f3a40 (LWP 6164))


    

  • 
#0
WebCore::AccessibilityObject::accessibilityPlatformIncludesObject() const

    
                from
                /lib64/libwebkitgtk-3.0.so.0

    

    • 

  • 
#1
WebCore::AccessibilityRenderObject::computeAccessibilityIsIgnored() const

    
                from
                /lib64/libwebkitgtk-3.0.so.0

    

    • 

  • 
#2
WebCore::AXObjectCache::notificationPostTimerFired(WebCore::Timer<WebCore::AXObjectCache>*)

    
                from
                /lib64/libwebkitgtk-3.0.so.0

    

    • 

  • 
#3
WebCore::ThreadTimers::sharedTimerFiredInternal()

    
                from
                /lib64/libwebkitgtk-3.0.so.0

    

    • 

  • 
#4
WebCore::timeout_cb(void*)

    
                from
                /lib64/libwebkitgtk-3.0.so.0

    

    • 

  • 
#5
g_timeout_dispatch

    
                from
                /lib64/libglib-2.0.so.0

    

    • 

  • 
#6
g_main_context_dispatch

    
                from
                /lib64/libglib-2.0.so.0

    

    • 

  • 
#7
g_main_context_iterate.isra

    
                from
                /lib64/libglib-2.0.so.0

    

    • 

  • 
#8
g_main_loop_run

    
                from
                /lib64/libglib-2.0.so.0

    

    • 

  • 
#9
gtk_main

    
                from
                /lib64/libgtk-3.so.0

    

    • 

  • 
#10
main

    • 

  • 
#0
WebCore::AccessibilityObject::accessibilityPlatformIncludesObject() const

    
                from
                /lib64/libwebkitgtk-3.0.so.0

    

    • 

  • 
#1
WebCore::AccessibilityRenderObject::computeAccessibilityIsIgnored() const

    
                from
                /lib64/libwebkitgtk-3.0.so.0

    

    • 

  • 
#2
WebCore::AXObjectCache::notificationPostTimerFired(WebCore::Timer<WebCore::AXObjectCache>*)

    
                from
                /lib64/libwebkitgtk-3.0.so.0

    

    • 

  • 
#3
WebCore::ThreadTimers::sharedTimerFiredInternal()

    
                from
                /lib64/libwebkitgtk-3.0.so.0

    

    • 

  • 
#4
WebCore::timeout_cb(void*)

    
                from
                /lib64/libwebkitgtk-3.0.so.0

    

    • 

  • 
#5
g_timeout_dispatch

    
                from
                /lib64/libglib-2.0.so.0

    

    • 

  • 
#6
g_main_context_dispatch

    
                from
                /lib64/libglib-2.0.so.0

    

    • 

  • 
#7
g_main_context_iterate.isra

    
                from
                /lib64/libglib-2.0.so.0

    

    • 

  • 
#8
g_main_loop_run

    
                from
                /lib64/libglib-2.0.so.0

    

    • 

  • 
#9
gtk_main

    
                from
                /lib64/libgtk-3.so.0

    

    • 

  • 
#10
main

    • 








But I don't have a org.gnome.desktop.interface key in dconf.  I don't use the GNOME desktop either though, so perhaps that's not surprising.  But how to apply  the workaround in comment #1 in that case?






Comment 11


Milan Crha





          2014-09-09 07:19:33 UTC
        



(In reply to comment #10)
> But I don't have a org.gnome.desktop.interface key in dconf.  I don't use the
> GNOME desktop either though, so perhaps that's not surprising.  But how to
> apply  the workaround in comment #1 in that case?

That's a question for WebKit folks, those whom take care of the WebKit's accessibility code. I'm afraid that they run this "preparation" code every time, regardless of the enabled accessibility, which doesn't explain why would the workaround from comment #1 work earlier.

In any case, despite the key's name, this is also used by gtk, thus any gtk-based application depends on it, whether it's run under GNOME desktop or not.






Comment 12


Brian J. Murrell





          2014-09-09 11:30:39 UTC
        



But even that workaround in comment #1 does not seem to be eliminating the issue for me.  Or not enough that I am patient enough to wait for it to complete.

So maybe it could be reducing the rendering down from many hours (not an exaggeration -- I have had messages take literally many hours to render) to a few, or even one hour and I wouldn't notice because I am not going to wait even an hour for it to complete rendering.  IOW, whether it's 5 minutes or 5 hours or 5 days, makes no difference.  They are all too long to wait.

And yes, I understand this is not an evolution problem directly.  I'm just making the point as to how it's affecting evolution but more importantly how the workaround in comment #1 is insufficient.