New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experimental backend for QtWebEngine (Blink) #615

Closed
Emdek opened this Issue Dec 27, 2014 · 42 comments

Comments

Projects
None yet
@Emdek
Member

Emdek commented Dec 27, 2014

Qt 5.4 introduced initial version of QtWebEngine, which allows to use Blink rendering engine in Qt applications without additional effort.
While APIs are still very basic it is already possible to use it for web browsing (as long as you don't care about cookies, history, plugins, searching, caching, transfers, user agent, context menus and other stuff).
So we should start preparations to take advantage of that new Qt module by creating new, experimental backend (note that we will continue to support QtWebKit even when QtWebEngine will become mature), possibly adding some workarounds where possible (some stuff can be done using JavaScript, since it is possible to execute it from C++ even when it is disabled for webpage) and waiting for basic APIs to arrive in Qt 5.5 and 5.6 (note that there are no plans for QNetworkAccessManager integration, at least not for now - that integration would allow to reuse lots of code from QtWebKit, taking care of cookies, transfers, user agent, cache etc.).
Our APIs were designed for supporting multiple backends from beginning, the only missing part being configuration UI for selecting default one plus additional changes for loading backends as separate plugins (can be done later).
This backend would be build only when asked to by setting compile time option, it's important to note that it has higher requirements for compilers (it's an issue in case of 32 bit platforms, especially Windows).
It will be turned on when it will be become usable enough and later will become default one (QtWebKit may end up as being disabled by default), we could make it requirement for 2.0 milestone to have it fully functioning.
It would be nice to have initial version available for next milestone.

@Katarn

This comment has been minimized.

Contributor

Katarn commented Dec 27, 2014

note that there are no plans for QNetworkAccessManager integration, at least not for now

I read somewhere in the press release that the functionality of this module is deployed to the other two. Now I can not find the details. Maybe it is? http://qt-project.org/wiki/QtWebEnginePortingFromQtWebKit#c8d4911a79ee66d17426afdd9b72c767

note that we will continue to support QtWebKit even when QtWebEngine will become mature

About it writes, that pretty soon it will put the deprecated status.

@Emdek

This comment has been minimized.

Member

Emdek commented Dec 27, 2014

@Katarn, it seems that originally they wanted to have integration but decided against to cut maintenance costs (as it is not trivial task and probably would degrade network performance a bit) and get ready to use product earlier.
QtWebKit is already deprecated (I would go for marking it that way when it will be actually possible to replace it, but that is up to them to decide) as of Qt 5.4, but it will be still maintained during Qt5 time line (so just fixes and likely no new features).

@Emdek

This comment has been minimized.

Member

Emdek commented Jan 12, 2015

So it begins. ;-)

This backend is disabled by default and requires command line option to be built (and Qt 5.4):
cmake -DEnableQtwebengine=ON ../
To set it as default backend you will need to set Backends/Web to qtwebengine.

Please note that this backend doesn't do much right now, it just loads pages and respects few basic options.

Emdek added a commit that referenced this issue Jan 19, 2015

@wblgrh

This comment has been minimized.

wblgrh commented Nov 14, 2015

@Chocimier, Me talking gibberish? Read again what you quoted, please. I said, they aim to control everything, why they would make an exception with Blink?
Also i told earlier, that there is no evidence about Blink being harmful, but there is no evidence for the opposite either; it's about being careful.
So, it's you who talking gibberish, but it's not a surprise from someone who cannot read even an one-lined quote.

But since, it's your project, be as your wish, i'm leaving. Be happy. Google is watching you.

@LimboSlam

This comment has been minimized.

LimboSlam commented Nov 14, 2015

@GungnirInd: Thanks for clearing that up and the helpful link. So does Otter have plans for CEF3 since CEF1 and 2 is dead.

Also @wblgrh: Please calm down, I'm sure it was a misunderstanding on both of your parts. :)

@xploSEoF

This comment has been minimized.

xploSEoF commented Nov 14, 2015

@wblgrh please check your "facts" before posting statements such as "Blink is a fork of WebKit, which was done by google" - it wasn't, and if it were, you realise you're argueing for continued use of Webkit?! Webkit was (and still is) open source, built on KDE libraries. You're fighting a battle with direction, evidence or realism - take a step back and reassess what you're doing. Don't make more statements without sources that can't be verified with a quick search (oh the irony, most people will search via Google). Most importantly, please calm down.

If you feel what you're saying is falling on deaf ears, perhaps it's not the ears that are deaf, but the words are actually just white noise that blends into the background. Repeating oneself and expecting a different outcome is rather insane, so perhaps once QtWebKit is no longer supported, Otter will no longer be a browser for you.

@Emdek Perhaps it's time to lock out this "issue"?

@wblgrh

This comment has been minimized.

wblgrh commented Nov 14, 2015

"Blink is a fork of WebKit, which was done by google" - it wasn't

https://en.wikipedia.org/wiki/Blink_(web_engine)

It is a fork of the WebCore component of WebKit

It wasn't, you say?

you realise you're argueing for continued use of Webkit?!

No. I arguing aganist something which is now controlled by google.

Webkit was (and still is) open source, built on KDE libraries.

I know what is KHTML, but i don't know how this related here.

If you feel what you're saying is falling on deaf ears, perhaps it's not the ears that are deaf, but the > words are actually just white noise that blends into the background.

Or maybe it's not white noise, you just cannot interpret the meaning.

perhaps once QtWebKit is no longer supported, Otter will no longer be a browser for you.

Yes. This is what i was afraid of.

But this was my last message, for i got only false statements or hate messages/personal attacks in response, (and they say, i should calm down; do you think that "gibberish talk" or "get out of here" is a polite and calm way of communicating?); i've bet, that there will be a response like "why did you came back"...

I just wanted to bring the attention to a possible danger, but if nobody care, then neither i won't.

@francoism90

This comment has been minimized.

francoism90 commented Feb 12, 2016

The adblocker doesn't work when using qtwebengine as backend.
Hope you guys can port it. :)

@Emdek

This comment has been minimized.

Member

Emdek commented Feb 16, 2016

@francoism90, that will be possible (at least partially) after updating to Qt 5.6 (should be release soon).

@francoism90

This comment has been minimized.

francoism90 commented Feb 17, 2016

@Emdek OK, thanks for the info. (Y)
Keep up the good work. :)

@VSHY

This comment has been minimized.

VSHY commented Mar 3, 2016

Qt 5.6 should be realised today :)

Added:
32-bit 113-build with Qt 5.6 RC on Win64 contains some "features")):

  • There is "SSL: undefined" on the About Otter window.
  • Text typing in any field sometimes leads to crash browser. Possible reason - I use Punto Switcher, but builds with QtWebKit does not lead to this result.
  • Right click and so on...

But we do not lose hope! :-)

Updated:
Qt 5.6 release was postponed to March 16 :(
On the other hand, there is the opportunity to experiment at RC :)

Emdek added a commit that referenced this issue Mar 19, 2016

[QtWebEngine] Change state when rendering process crashes using worka…
…round for borked signal declaration in QtWebEngine, references #615

bajasoft added a commit to bajasoft/otter that referenced this issue Mar 24, 2016

@Emdek Emdek closed this Sep 19, 2016

@Emdek

This comment has been minimized.

Member

Emdek commented Sep 19, 2016

We already exposed almost everything that could be exposed with current APIs provided by QtWebEngine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment