Bug 143622

Summary: Google+ pages freeze when load completes
Product: WebKit Reporter: Michael Catanzaro <mcatanzaro>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: cgarcia, georges.stavracas, mcatanzaro, nekohayo, rodrigo5244
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   

Description Michael Catanzaro 2015-04-10 16:27:12 PDT
Log into a Google account and visit plus.google.com. The web view freezes once the page stops loading, in both 2.8.0 and master. Scrolling through the rendered portion of the page works perfectly fine until the load completes. Not really sure what to do to debug this.

This bug existed about a year ago, too, but it was mysteriously fixed at some point....
Comment 1 Michael Catanzaro 2015-06-08 07:26:44 PDT
I'm told the same symptoms occur on Google Drive and Lifehacker.

Here's a useless backtrace from the "hung" web process (it's not really hung, just seems so since scrolling is broken):

Thread 1 (Thread 0x7f0961b97a00 (LWP 7370)):
#0  0x00007f0956b5066d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f095c448dbc in g_main_context_iterate (priority=2147483647, n_fds=6, fds=0x7f0963e708c0, timeout=<optimized out>, context=0x7f0961cde6d0)
    at gmain.c:4103
        poll_func = 0x7f095c458500 <g_poll>
        max_priority = 2147483647
        timeout = 140
---Type <return> to continue, or q <return> to quit---
        some_ready = <optimized out>
        nfds = 6
        allocated_nfds = 14
        fds = 0x7f0963e708c0
#2  0x00007f095c448dbc in g_main_context_iterate (context=0x7f0961cde6d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3803
        max_priority = 2147483647
        timeout = 140
        some_ready = <optimized out>
        nfds = 6
        allocated_nfds = 14
        fds = 0x7f0963e708c0
#3  0x00007f095c449142 in g_main_loop_run (loop=0x7f09623a6600) at gmain.c:4002
        __func__ = "g_main_loop_run"
#4  0x00007f096112afa0 in WTF::RunLoop::run() ()
    at /lib64/libwebkit2gtk-4.0.so.37
#5  0x00007f095ff156aa in int WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**) () at /lib64/libwebkit2gtk-4.0.so.37
#6  0x00007f0956a7a790 in __libc_start_main (main=
    0x7f0961be9c10 <main>, argc=2, argv=0x7ffe83186238, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe83186228)
    at libc-start.c:289
        result = <optimized out>
---Type <return> to continue, or q <return> to quit---
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {0, 4114938953717356800, 139678271315008, 140731097834032, 0, 0, 4104176055984429312, 4114985073412774144}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7ffe83186250, 0x7f0961be8148}, data = {prev = 0x0, cleanup = 0x0, canceltype = -2095553968}}}
        not_first_call = <optimized out>
#7  0x00007f0961be9c69 in _start ()
Comment 2 Michael Catanzaro 2015-06-08 07:41:55 PDT
feaneron:  mcatanzaro: against what you just said, scrolling ~does~ work on the hanged page
feaneron:  mcatanzaro: but the page isn't rendered to match it
feaneronknows every aspect of these hangs - he really tried to fix it, but gave up after reading webkitgtk's colossal code
mcatanzaro:  Hm, the scrollbar stays still for me
feaneron:  mcatanzaro: yes, it won't get re-rendered
feaneron:  mcatanzaro: but you can see that scrolling happens by the mouse pointer
feaneron:  e.g. the search bar hides when you scroll down
mcatanzaro:  feaneron: Interesting... for me, the search bar does NOT hide when I scroll down, but when I type into the search bar the page becomes un-stuck
mcatanzaro:  And that seems to "fix" the hang reliably for me.
feaneron:  I envy you
mcatanzaro:  feaneron: What version of WebKitGTK+?
– svillar has joined the room
feaneron:  mcatanzaro: 2.8.3-1
mcatanzaro:  Me too, strange.
Comment 3 Michael Catanzaro 2015-07-19 09:57:36 PDT
If you resize the page to be larger, the newly-exposed portion of the page will be completely white during this "hang."
Comment 4 Michael Catanzaro 2015-07-19 09:59:54 PDT
By the way, the workaround in comment #2 is still reliable for me: Ctrl+F and type anything into the search box, and you'll regain control of the page.
Comment 5 Jeff Fortin 2015-07-19 10:26:22 PDT
It also seems to me, from my testing, that that the freeze will occur if you let the page load fully without doing anything, but can be prevented "most of the time" if you scroll while the page is loading. Not 100% reliable though.
Comment 6 Jeff Fortin 2015-07-31 10:50:13 PDT
Interestingly enough, the same symptom sometimes happens on http://www.meteomedia.com/meteo/canada/quebec/montreal (less frequently than on G+, it seems)
Comment 7 Georges Basile Stavracas Neto 2015-09-25 05:28:36 PDT
With WebkitGtk 2.10.0 + Epiphany 3.18.0, this behavior happens no more. Can someone confirm that so we can close this bug report?