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 746166 - Disable some WebKit features we don't need
Disable some WebKit features we don't need
Status: RESOLVED FIXED
Product: devhelp
Classification: Applications
Component: General
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: devhelp-maint
devhelp-maint
Depends on:
Blocks:
 
 
Reported: 2015-03-13 16:50 UTC by Michael Catanzaro
Modified: 2015-05-31 02:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (1.58 KB, patch)
2015-03-13 16:50 UTC, Michael Catanzaro
committed Details | Review
Use one WebKitSettings for each web view (16.61 KB, patch)
2015-03-22 15:54 UTC, Michael Catanzaro
none Details | Review

Description Michael Catanzaro 2015-03-13 16:50:20 UTC
Created attachment 299338 [details] [review]
patch

Disable some WebKit features we don't need. Avoid weird crashes like https://bugzilla.redhat.com/show_bug.cgi?id=1201823 which should not be   happening at all, because developer documentation does not need HTML5 local storage.
Comment 1 Carlos Garcia Campos 2015-03-16 14:44:11 UTC
Review of attachment 299338 [details] [review]:

::: src/dh-window.c
@@ +1219,3 @@
         /* Prepare the web view */
         view = webkit_web_view_new ();
+        apply_webview_settings (WEBKIT_WEB_VIEW (view));

Instead of applying these settings to every new web view created, I think we should have a global WebKitSettings object, created with those settings initially (webkit_settings_new_with_settings), and share that settings object among all web views (webkit_web_view_new_with_settings). That would also fix another problem in devhelp, that changing the fonts or font size only applies to the current tab.
Comment 2 Frederic Peters 2015-03-16 14:47:54 UTC
Ok, I pushed that one already as I was about to roll the tarball for .92 but if there's a patch update today I'll gladly accept it.
Comment 3 Michael Catanzaro 2015-03-16 21:37:17 UTC
I've tentatively added the WebKitSettings object as a member of the singleton DhSettings class, which is where all the gsettings code is.

(In reply to Carlos Garcia Campos from comment #1)
> That would
> also fix another problem in devhelp, that changing the fonts or font size
> only applies to the current tab.

Hm, it's a bit more complicated than this. There is code to update the font on each tab, but it's only partially working. I don't have time to look into this more before freeze, because my jhbuild development copy of WebKit is in no state for testing things right now. But I'll try to have a new patch "soon."
Comment 4 Frederic Peters 2015-03-16 21:48:46 UTC
That's fine; it's now hard code freeze but we can get the patch in for 3.16.1.
Comment 5 Michael Catanzaro 2015-03-22 14:58:44 UTC
So the status quo in 3.14 is that font size is updated immediately in every tab in every window (i.e. it's already correct), as does checking or unchecking "use system fonts", but changing to a different font does not work at all ever, not even if I restart devhelp.
Comment 6 Michael Catanzaro 2015-03-22 15:03:16 UTC
Well I guess the fonts are set by the HTML... maybe having the setting at all is more confusing than it's worth
Comment 7 Michael Catanzaro 2015-03-22 15:54:39 UTC
Created attachment 300079 [details] [review]
Use one WebKitSettings for each web view

Here is the promised patch, but I'm not sure if we should apply it because (a) it doesn't fix anything (changing fonts across multiple tabs and windows already works fine for me, except that setting a default font family is rather useless), and (b) using one WebKitSettings object means we need to remove all the code that previously painstakingly ensured that devhelp would automatically adjust font size per-window if one screen had different DPI than another, so it will introduce a regression.

I wish apps didn't have to handle DPI themselves.
Comment 8 Michael Catanzaro 2015-05-31 01:58:01 UTC
I reject my patch for the reasons above. Let's close this bug. :)