Skip to content
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

update to build with mono 4.0, and also make it work. #1

Open
wants to merge 11 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@HinTak
Copy link

commented Jan 12, 2016

Should be obvious.

@HinTak

This comment has been minimized.

Copy link
Author

commented May 21, 2016

@shana : ping - how I can get this small change merged?

@HinTak

This comment has been minimized.

Copy link
Author

commented May 21, 2016

Filed two bugs at xamarin, just in case it is useful...

https://bugzilla.xamarin.com/show_bug.cgi?id=41228
Going through windows.forms/mono-webbrowser, loses all html colors/layouts
https://bugzilla.xamarin.com/show_bug.cgi?id=41230
windows.forms/mono-webbrowser hangs on shutting down.

@HinTak

This comment has been minimized.

Copy link
Author

commented May 21, 2016

@shana - found
https://bugzilla.novell.com/show_bug.cgi?id=666033#c15 where you wrote "webkit alternative is not ready yet" . That was almost a year after the last commit on mono-webbrowser. Would it be correct to say that the lacking-color/layout and hang-on-exit issues part of 'not ready'? I am just trying to understand if the code did work correctly at one point in the past, or not (and worth trying to find out when it broke...). Thanks.

I picked this path because libgluezilla does not build, and at least webkit-sharp seems more actively maintained.

@shana

This comment has been minimized.

Copy link
Member

commented May 26, 2016

I've not maintained this project for many years, as you've noticed. I have no idea in what state it's in.

Nowadays, webkit bindings are generated with bindinator (https://github.com/shana/bindinator), and you can find some recent generated bindings at https://github.com/hbons/webkit2-sharp or https://github.com/stsundermann/webkitgtk-sharp. These bindings are the backend to what mono-webbrowser needs, but unfortunately mono-webbrowser isn't really complete enough with webkit to work properly.

Not sure what to tell you, I'm afraid most of winforms is not maintained anymore 😞

@shana

This comment has been minimized.

Copy link
Member

commented May 26, 2016

That said, I'll be happy to merge your change if that helps!

@HinTak

This comment has been minimized.

Copy link
Author

commented May 27, 2016

I tried https://github.com/stsundermann/webkitgtk-sharp and it is quite reassuring that your 12-line webbrowser example works as is (adjusted for -r:). I tried moving mono-webbrowser onto the newer gtk3 APIs and got something that compiles, but fails at run time with a 'cannot mix gtk2 and gtk3' error. Then I remember that Mono.WebBrowser/Mono.Mozilla provides Mono.WebBrowser.Platform.Gtk so it probably depends on gtk2 :-(. I'll have a look at https://github.com/hbons/webkit2-sharp next.

@shana : My main question is: to what extent mono-webbrowser worked in 2010/2011? i.e. is the 'missing all color/layout' and 'hang/crash on exit' problems now regressions or have they always been there?

As I said I already tried moving mono-webbrowser to the gtk3-based webkitgtk-sharp, and at least learned one thing: I'll need to stay with gtk2, which is one useful piece of info.

This pull is fairly obvious - just to make it buildable with current mono 4.x.

@HinTak

This comment has been minimized.

Copy link
Author

commented May 27, 2016

I just gave https://github.com/hbons/webkit2-sharp a try, and it seems to work okay directly ( hbons/webkit2-sharp#1 ) . Hoever it is also gtk3 based, which is no-go as far as mono-webbrowser/system.window.forms goes, I think. Unless I change mono's system.window.forms, I guess...

Dispose() on Shutdown(), to allow shutting down cleanly.
Mono's SWF.WebBrowserBase does not ever call IWebBrowser.Dispose() - instead it
calls IWebBrowser.Shutdown() on Dispose(). So we clean up in our Shutdown().

Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
@HinTak

This comment has been minimized.

Copy link
Author

commented May 27, 2016

@shana : what do you think of the shutdown fix?

@HinTak

This comment has been minimized.

Copy link
Author

commented Jun 6, 2016

@shana : this is exciting!!!! I have got it working, finally!!!! Shall clean up and push soon!!!! Who do I need to hassle to get it merged?

HinTak added some commits Jun 6, 2016

Run the GTK event loop from the System.Windows.Forms Idle event handl…
…er, instead of Gdk.Thread.

This change was inspired by the Linux/mono SWF code in
https://bitbucket.org/geckofx/ .

The problem is that the Gdk.Thread model does not work well with mono's
implementation of System.Threading.Thread . Here are two symptoms:
(Actually the hang-on-shutdown is a different problem, but the issue
mentioned therein about the browser window not responding well to resize,
etc is)

https://bugzilla.xamarin.com/show_bug.cgi?id=41228
Going through windows.forms/mono-webbrowser, loses all html colors/layouts
https://bugzilla.xamarin.com/show_bug.cgi?id=41230
windows.forms/mono-webbrowser hangs on shutting down.

This change makes it work well enough with single browser window usage. I'll
update further to allow multiple instances.

@HinTak HinTak changed the title update to build with mono 4.0 update to build with mono 4.0, and also make it work. Jun 6, 2016

@HinTak

This comment has been minimized.

Copy link
Author

commented Jun 6, 2016

While tidying up I realize that the new code, though working so much better, only works for one browser instance, because it runs Gtk.Application.Init() from Load(). Still, it is working well enough, and quite a lot better than before for that particular usage. I think this can be merged.

I'll re-use some of the old code for locks and reference-counts .

HinTak added some commits Jun 6, 2016

re-instating all the locks to allow exactly one instance of Gtk.Appli…
…cation and one hook of Idle event delegate for multiple broswer instances
@HinTak

This comment has been minimized.

Copy link
Author

commented Jun 6, 2016

@shana : BTW, I have also a heavily updated webkit-sharp (webkit1-gtk2) to 2.4.11 api. It is based on bindinator's and adapted for gtk2. I found that the api.raw file coming out of bindinator stopped working for gapi2-codegen after

From 146126261e333dd179da42d2b088d2598b590dda Mon Sep 17 00:00:00 2001
From: Andreia Gaita <shana@spoiledcat.net>
Date: Fri, 21 Sep 2012 13:24:34 +0100

Still, it offers a lot more in-depth API than the older webkit-sharp; just turned out that for my purpose (I just need a simple embedded webbrowser without changing SWF-related code) the old code works well enough; but some might like to upgrade to the more extensive 2.4.11 api even if they are still stuck with gtk2. We'll continue that other thought in shana/bindinator#28 , but for now, mono-webbrowser is working well!!!!

@shana

This comment has been minimized.

Copy link
Member

commented Jun 6, 2016

To be honest, I'm not sure how we're packaging this or whether I can do a new version for mono, but I'll investigate!

@shana

This comment has been minimized.

Copy link
Member

commented Jun 6, 2016

(and I'll look at this as soon as I can tomorrow)

@HinTak

This comment has been minimized.

Copy link
Author

commented Jun 7, 2016

4 simultaneous embeded browser instances:
http://htl10.users.sourceforge.net/FontVal-Linux-xml-tiled.png

It even works with win32 mono (with win32 webkit, etc) - the simple test example:
http://htl10.users.sourceforge.net/win32-mono-webkit-2.png

I don't think you need to worry about packaging . Mono relies on a secret handshake MONO_BROWSER_ENGINE=webkit to look for it . If mono cannot find mono-webkit.dll in the assembly load path, it goes back to looking for libgluezilla, which is exactly what it is doing without the secret handshake. It would be nice to permanently enable the secret handshake (since it does no harm at all), but
mono-webbrowser can stay separate (and should, since it depends on webkit-sharp, which is separate). It would be nice to push a working version of this code upstream to let more people know about it, as libgluezilla has not been working for some 5 years now.

I know there are other embedded browser out there. However, this (and libgluezilla) is the only way which does not involve modifying already-working-well-on-windows code with MSIE on windows.

I have opened my issue tracker
https://github.com/HinTak/mono-webbrowser/issues
to keep tab on a couple of small issues I might continue on.

@HinTak

This comment has been minimized.

Copy link
Author

commented Jun 7, 2016

What made me switch the event loop in the end, was that I added some code to watch the events in the inner most webview widget, and I saw that they never got fired; also some internal structures don't get filled (with an augmented webkit-sharp gtk2 from a more recent bindinator hack). It is as if the gtk events are not being generated/ran. The backend does not seem to notice the front got resized/minimized/maximized. So I don't understand why the switch works, except it does, and geckofx has a SWF-idle driven event loop and it is still being used, so it must be doing something right and I drew on it.

I think the "bitrot" is likely due to buffering/compositing window managers.

@HinTak

This comment has been minimized.

Copy link
Author

commented Jun 9, 2016

One issue I spent a lot of time on in the old code, is that, if you resize->minimize->maximize, the window get reset to the original size. I haven't checked the SWF event loop then - I thought it was gtk not received screen-need-to-update signals then - but the SWF control under that situation never receive anything about a size change, so it keeps telling the containing widget what it remembers, on maximizing.

Thinking along that line, maybe the problem with the old code isn't that the gtk event loop not getting any events, but that it is getting all of it. Resizing should come from the SWF container, rather than gtk dealing with user input itself. That's maybe why the new code works - in the new code, gtk events are only dealt with when SWF is not busy.

This is all very hand-waving - I am just trying to understanding why the code change works, and whether there is any better way towards taking advantage of the older threaded approach.

@HinTak

This comment has been minimized.

Copy link
Author

commented Jun 10, 2016

xwt has a rather interesting and cryptic change about limiting Gtk.Application.EventsPending() to 1000 in 59c6997d583f9dee0ea29bda38d0a43e7ff193b4 from @slluis . I wonder if @slluis can say tell us about that?

@HinTak

This comment has been minimized.

Copy link
Author

commented Jun 16, 2016

@slluis @shana : I have made another interesting change - which I'll possibly put onto a branch - to use a Xwt backend instead of webkit-gtk2.

Obviously that's stupid for both Linux and windows:

  • on Linux, Xwt uses either webkit-gtk2 or webkit-gtk3, and since Mono's SWF is gtk2-dependent and one can't mix gtk2 and gtk3, doing SWF->mono-webbrowser->Xwt->Gtk2 is just an extra layer
  • on windows, Xwt uses SWF, so SWF->mono-webbrowser->Xwt->SWF is probably going to deadlock :-).

But I am looking at an interesting possibility, for Mac OS X: SWF->mono-webbrowser->Xwt->Gtk->Gtk.Mac->MonoMac. i.e. using Mac OS X's webkit to support SWF via Xwt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.