Use GTK3 by default (with WebKit2)

Bug #898496 reported by Cassidy James Blaede
100
This bug affects 22 people
Affects Status Importance Assigned to Milestone
Midori Web Browser
Fix Released
High
Unassigned
Fedora
Fix Released
Medium
midori (Debian)
Fix Released
Unknown

Bug Description

I understand that GTK3 support is underway, but it'd be great to be able to get it as the default on supported systems.

Tags: gtk3 webkit2

Related branches

Cris Dywan (kalikiana)
tags: added: gtk3
Revision history for this message
Cris Dywan (kalikiana) wrote :

It will be the default if it is on par with GTK+ 2. See https://wiki.xfce.org/midori/roadmap#gtk_30gtk_32_build for a list of issues and tested versions.

Changed in midori:
status: New → In Progress
importance: Undecided → High
Revision history for this message
Cris Dywan (kalikiana) wrote :

I figure to proceed here, we probably need strict minimum version checks. GTK+ 3.2.3 WebKitGTK+ 1.6.3 are supposedly a combination that works without hitting bug 902594. If that can be confirmed we could require it.

Revision history for this message
Xristh (prflr) wrote :

For the record: compilling 0.5.4 or the latest bzr in GTK3 give the next problems:

* Unable to tweak font size because no textbox exist
* Icon size throw preferences are ignored
* a page wrong loaded (this one for example) crash ALL the other too
* wrong string in version (0..4 in about become midori_0.5.4_ in spanish, but is fixed in bzr)
* crash, or close and open clear all my password instead f keep them

Open a bug for every problem??

Revision history for this message
Cris Dywan (kalikiana) wrote :

I heard a suggestion to promote GTK+3 as a default together with WebKit2 when it's ready - for many people Netscape plugins are the only problem they have with GTK+3. For the record, I find this an acceptable requirement - I don't think anything else whatsoever is wrong with GTK+3 at this point.

tags: added: webkit2
summary: - Use GTK3 by default
+ Use GTK3 by default (with WebKit2)
Cris Dywan (kalikiana)
Changed in midori:
milestone: none → 0.6.0
Revision history for this message
In , Raphael (raphael-redhat-bugs) wrote :

Description of problem:
From upstream bug: I understand that GTK3 support is underway, but it'd be great to be able to get it as the default on supported systems.

Version-Release number of selected component (if applicable):
0.6+

How reproducible:
yes

Steps to Reproduce:
1. install latest development branch
2.
3.

Actual results:
Gtk2 will go obsolete.

Expected results:
Use Gtk3

Additional info:

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

In the past gtk3/webkit2 support was lacking a number of things.

We will of course move to it with the next version as that will be gtk3/webkit2 only.

I'm not sure what all you are asking here... the above is the plan, just need upstream to release 0.6.0 and rawhide will get it. ;) I don't really want to drop a snapshot in...

Revision history for this message
In , Raphael (raphael-redhat-bugs) wrote :

(In reply to Kevin Fenzi from comment #1)
> In the past gtk3/webkit2 support was lacking a number of things.

Because there's no official 0.6.0 release currently, those issues should be reported to upstream.

> We will of course move to it with the next version as that will be
> gtk3/webkit2 only.

Nice. But it will break with the gtk2 enforcement as a (nice to have?) requirement of the Xfce spin. Since Xfce is delayed further with official(!) Gtk3 support, I am not sure if we could still promote Midori/Gtk3 as a featured part of it.

> I'm not sure what all you are asking here... the above is the plan, just
> need upstream to release 0.6.0 and rawhide will get it. ;) I don't really
> want to drop a snapshot in...

Well, it's requested for rawhide only, at the moment. Maybe it's even worth a RFE for Fedora 22? What do you think? It may depend who is releasing faster, upstream or Fedora … :)

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

(In reply to Raphael Groner from comment #2)
> (In reply to Kevin Fenzi from comment #1)
> > In the past gtk3/webkit2 support was lacking a number of things.
>
> Because there's no official 0.6.0 release currently, those issues should be
> reported to upstream.

Sure. But landing it in rawhide when it's lacking a bunch of things is more likely to cause people to just use some other browser.

>
> > We will of course move to it with the next version as that will be
> > gtk3/webkit2 only.
>
> Nice. But it will break with the gtk2 enforcement as a (nice to have?)
> requirement of the Xfce spin. Since Xfce is delayed further with official(!)
> Gtk3 support, I am not sure if we could still promote Midori/Gtk3 as a
> featured part of it.

I'm not sure where you see that requirement. We have a number of gtk3 items on the Xfce spin right now... this would simply be one more.

> > I'm not sure what all you are asking here... the above is the plan, just
> > need upstream to release 0.6.0 and rawhide will get it. ;) I don't really
> > want to drop a snapshot in...
>
> Well, it's requested for rawhide only, at the moment. Maybe it's even worth
> a RFE for Fedora 22? What do you think? It may depend who is releasing
> faster, upstream or Fedora … :)

I'm not going to land a snapshot in rawhide, at least without more data on how functional it is.
This seems like a fine use for a copr... would you be willing to make one? Or I could do so.

Revision history for this message
In , Raphael (raphael-redhat-bugs) wrote :

(In reply to Kevin Fenzi from comment #3)

> I'm not going to land a snapshot in rawhide, at least without more data on
> how functional it is.
> This seems like a fine use for a copr... would you be willing to make one?
> Or I could do so.

I am already working on some copr builds. It turns out that Fedora20 is too old with the versions for all those dependencies: vala, gtk, webkit. So adjusting the spec file for F21+, please stay tuned.

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

(In reply to Raphael Groner from comment #4)

> I am already working on some copr builds. It turns out that Fedora20 is too
> old with the versions for all those dependencies: vala, gtk, webkit. So
> adjusting the spec file for F21+, please stay tuned.

Great. Please do let me know when you have the copr ready, I'd be happy to help test.

I might also make a local rawhide build to play with it some...

Revision history for this message
In , Raphael (raphael-redhat-bugs) wrote :

Trunk upstream has planned a further release …
Midori 0.6.0 "All for one, One for all"
https://launchpad.net/midori/+milestone/0.6.0

Revision history for this message
In , Raphael (raphael-redhat-bugs) wrote :

I can confirm that there are issues with responsiveness on javascript pages. Therefore my suggestion to delay any new builds and continue to monitor upstream activity.

Revision history for this message
In , Michael (michael-redhat-bugs) wrote :

(In reply to Kevin Fenzi from comment #1)
> In the past gtk3/webkit2 support was lacking a number of things.

Hi, I work on WebKitGTK+. We only support GTK+ 3 and WebKit2 nowadays; WebKit1 doesn't get security updates anymore, so I recommend moving to WK2 as fast as possible. WK2 nowadays is more mature and robust than WK1. If there are any particular issues with migration to WK2, I'd appreciate a heads-up.

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

midori will move to gtk3/webkit2 as soon as it does upstream. ;)

They planned to last release, but it was taking longer than they expected.

Hopefully the next one will be.

Changed in midori (Debian):
status: Unknown → New
Revision history for this message
In , Michael (michael-redhat-bugs) wrote :

FYI, there have been 126 remote code execution vulnerabilities discovered in the past year since security updates for WebKitGTK+ 2.4 ended. I wouldn't consider upgrading to be low-priority....

Revision history for this message
In , Raphael (raphael-redhat-bugs) wrote :

Michael, don't confuse priority with severity. But your point is valuable as you mention about a lot of vulnerabilities, I'll remove low severity.

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

I'm aware of the urgency... but we can't (nor should we) force upstream to do what we want.

Revision history for this message
veyvr (chris-std) wrote :

This issue is getting more pressing every day since there are >100 known security issues in WebKit1 (for Gtk+). WebKit2 for Gtk+ doesn't have these issues. See https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ for details.

Browser plugins are less important every day and are discouraged by every major browser vendor for security reasons anyway. Usually browser plugin vendors don't care much about browser plugin security.

Revision history for this message
In , Raphael (raphael-redhat-bugs) wrote :

In assumption we can not do anything here in downstream, I'll change status back. Feel free to take this bug for any further work with Gtk3 and Webkit2. Although, I don't expect any big progress in near future cause WebKit major development is stalled in favor of new WebEngine project (- at least if we talk about Qt).

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

I've given up waiting on a upstream release and switched to the webKitTwoOnly branch that builds against webkit2.

It's a bit unstable under wayland (unless you run it with 'GDK_BACKEND=x11 midori'), but it does work.

Hopefully upstream will release a real version soon.

Changed in midori (Debian):
status: New → Fix Released
Changed in fedora:
importance: Unknown → Medium
status: Unknown → Fix Released
Revision history for this message
Cris Dywan (kalikiana) wrote :

The latest code is WebKit2 and GTK+3 only so as of the next release this is fixed.

Changed in midori:
status: In Progress → Fix Committed
Cris Dywan (kalikiana)
Changed in midori:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.