Bug 167735
Summary: | REGRESSION(r211486): [GTK] Loading pages is broken | ||
---|---|---|---|
Product: | WebKit | Reporter: | Tomas Popela <tpopela> |
Component: | Web Inspector | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | bugs-noreply, cgarcia, inspector-bugzilla-changes, joepeck, mcatanzaro |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=167683 |
Tomas Popela
Loading anything in MiniBrowser (or anywhere) after http://trac.webkit.org/changeset/211486 is broken. It's stuck during loading, nothing rendered.
0 $ git bisect log
git bisect start
# good: [46c3b891d84489a826ec06c302b184c157acbb65] Unreviewed. Fix coding style in MiniBrowser
git bisect good 46c3b891d84489a826ec06c302b184c157acbb65
# bad: [50ec0e2333f327d96bc3ac84e8c61ddb432c0eca] In iOS, we should take background assertion when accessing localstorage databases. https://bugs.webkit.org/show_bug.cgi?id=165478
git bisect bad 50ec0e2333f327d96bc3ac84e8c61ddb432c0eca
# bad: [4733eca73c76de4e89eaa4c145036c4f360cadc0] Clean up css3/filters/backdrop/backdrop-filter-with-clip-path.html expected results.
git bisect bad 4733eca73c76de4e89eaa4c145036c4f360cadc0
# bad: [b8dc1833d7aaed3f3eac3d773e5d2af96d55d7f9] Unreviewed build fix.
git bisect bad b8dc1833d7aaed3f3eac3d773e5d2af96d55d7f9
# bad: [5a559e130d3d070cb584a8d6f5210bed04a33439] AXObjectCache is missing two functions at link time when !HAVE(ACCESSIBILITY) https://bugs.webkit.org/show_bug.cgi?id=167691
git bisect bad 5a559e130d3d070cb584a8d6f5210bed04a33439
# good: [4260075a3191fcaf1859d8e08e95d065f115b158] Web Inspector: Remove keyboard shortcut to close tab - does not match expectations https://bugs.webkit.org/show_bug.cgi?id=167672
git bisect good 4260075a3191fcaf1859d8e08e95d065f115b158
# bad: [510ab9198e0c093e894a0a98f20cff7189572ab7] HTMLMediaElement.h fails to build when ENABLE(MEDIA_CONTROLS_SCRIPT) is false https://bugs.webkit.org/show_bug.cgi?id=167689
git bisect bad 510ab9198e0c093e894a0a98f20cff7189572ab7
# bad: [3f4d09e9ba5b9f7709eb74f8da91472f2db29014] Web Inspector: Use guaranteed RunLoop instead of RunLoop::current for dispatching inspector GC event https://bugs.webkit.org/show_bug.cgi?id=167683 <rdar://problem/30167791>
git bisect bad 3f4d09e9ba5b9f7709eb74f8da91472f2db29014
# first bad commit: [3f4d09e9ba5b9f7709eb74f8da91472f2db29014] Web Inspector: Use guaranteed RunLoop instead of RunLoop::current for dispatching inspector GC event https://bugs.webkit.org/show_bug.cgi?id=167683 <rdar://problem/30167791>
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Joseph Pecoraro
Errr wow. I guess step 1 is to rollout.
My best guess is that the main run loop initialization added to InitializeThreading doesn't happen on the main thread?!
Joseph Pecoraro
An alternative solution would be to guard the main run loop initialization in Source/JavaScriptCore/runtime/InitializeThreading.cpp with PLATFORM(COCOA) guards. That feels a bit arbitrary, but since I can't test GTK to understand what is happening, and since GTK doesn't currently use the JSContext inspector code, it should be just fine. If I don't hear back by the end of the day I'll speculatively land this change.
To start investigation a backtrace of all threads to see what is happening when RunLoop::initializeMainRunLoop is getting called on GTK would be important.
Michael Catanzaro
I'd rather fix it properly than add a strange PLATFORM(COCOA) guard adding even more platform-dependent behavior.
I didn't roll it out because our bots are not hitting this for some inexplicably reason, and since I know you can't test it. We'll figure something out. :)
Joseph Pecoraro
(In reply to comment #3)
> I'd rather fix it properly than add a strange PLATFORM(COCOA) guard adding
> even more platform-dependent behavior.
>
> I didn't roll it out because our bots are not hitting this for some
> inexplicably reason, and since I know you can't test it. We'll figure
> something out. :)
Thanks! My best guess is MiniBrowser does something that WebKitTestRunners don't and triggers JavaScriptCore's thread initialization on a background thread.
Carlos Garcia Campos
I missed this bug, but not #167776, where I submitted a patch, so marking this a dupl because the other one has a patch already. Please, guys, for GTK+ bugs remember to either use the WebKitGtk component or add webkitgtk to the CC
*** This bug has been marked as a duplicate of bug 167776 ***