New Gecko package

Jacek Caban jacek at
Mon May 28 11:27:50 CDT 2007

Vitaliy Margolen wrote:
> Jacek Caban wrote:
>> Vitaliy Margolen wrote:
>>>>> BTW why JavaScript doesn't work or any pop-up windows don't open? I know
>>>>> this works fine with Firefox.
>>>> It needs some support from Gecko embedder (MSHTML in our case) and I
>>>> haven't worked on it yet (with exception of built in alert pop-up).
>>> You mean that what Wine has now uses gecko for just HTML rendering and
>>> nothing else?! That you are pretty much rewriting the whole browser from
>>> the scratch?!! How is that better then what we had before?!!!
>> Well, it would be perfect if we used it only for rendering... but I
>> don't think we'll ever reach that state. Just take a look at how deep an
>> API may meddle with a HTML document. In case of pop-ups Gecko asks the
>> embedder to create the window. It's not like IE API, which is a complete
>> browser. Pop-up window is, in fact, a new IE window. Gecko isn't
>> anything like a complete web browser, it's just an engine. The embedder
>> creates a window and integrates it with its other windows. In case of
>> Wine it's not trivial, as this new window should be, in fact, an IE
>> window with its associated MSHTML object etc.
> So you want to say that we will never have pages with embedded
> JavaScript working in Wine?

It already works! I only said that pop-ups don't work.

>>> The impression you gave about a year ago that Mozilla active-X controls
>>> needed number of things modified, but other then that it worked fine.
>> And my impression was that people would like to use apps like Picasa and
>> Steam out of box with perspectives of getting much more instead of
>> having a lots of "won't fix" bugs.
> Indeed they would. Only I would say picasa to steam ratio would be
> 1-to-100.
Hm, where do you have those statistics from? How do you know how many
apps are *fixed* by switch to the new implementation?

>  And btw only most rudimentary things work in both! Steam
> worked _perfectly_ before. And I'm sure would still worked. But now, you
> can't buy stuff, you can't open screen-shots (because they are popups)
> you don't see MOTO when joining servers, lots of things do not work. So
> I would use Steam as an example on the contrary.

Steam didn't work at all unless you used Mozilla ActiveX control used by
TG that had some unacceptable forthe main Gecko tree hacks. I didn't
know about pop-ups in Steam. I've attached a hack from Picasa tree that
causes links opening in new window to be opened in winebrowser. It's a
nicer behavior than opening them in our IE replacement, but it's not
guaranteed to work (app doesn't have control over it, different cookie
manager...). As I wrote, correct implementation is much more
complicated, but we're getting nearer to it. Eg. implementing
InternetExplorer object (more or less that's what iexplore.exe is) was a
big step forward. Anyway if the attached patch helps, it may go to Git IMO.

>>> Here I see only most rudimentary things work, and everything else would
>>> probably never work. And Wine is open for stream of never ending
>>> security issues, that so far no one even risen.
>> Well, if you call apps like Outlook a rudimentary thing... Sure, there
> Yes they are! Most e-mails don't have anything even close to most simple
> website has.

Not from API point of view. First of all app has to be able to embed
HTML, then we can think about how nicely is HTML handled.

>> still is a lot to do, but with correct architecture we can support more
>> complex apps. Mozilla ActiveX control will never allow us to run
>> programs like Outlook. And it's not the only example. Pop-ups, in
>> particular, arn't too interesting as apps that embed HTML documents
>> don't usually use them.
> Ok if we can support more apps, then why aren't we?
Aren't we? Still more and more works. Take a look at number of MSHTML
patches. Do you think they are only to make Wine compilation time longer?

> Do you have a todo list?

Yes, fix a few MSHTML bugs I'm working ATM, then come back to activation
context to get it accepted to Wine. I usually target on a specific app
and fix it, so I have no clear todo list. There are a few hacks I'd like
to fix (we're slowly getting there) and find time to make bug hunting on
> Or at least a list of what needs to be done before we can open a
> stinking popup?
Test how exactly does WebBrowser/MSHTM/InternetExplorer interface in
this case and implement it or stay with the attached patch for now.
>  Or what all needs to be done to get JavaScrip working?

As I wrote, it works. JavaScript is not only for pop-ups.

>>> I hate to sound negative about things here, but how hard will it be to
>>> put things back the way they were before? Or at least make it possible
>>> to use Mozilla ActiveX controls instead of wine_gecko?
>> It'd be quite simple, but don't count on my support in it. I very much
>> disagree with such ideas and I prefer concentrating on improving MSHTML
>> rather than looking for ugly workarounds. Mozilla ActiveX control may
>> work only for WebBrowser control but it *can't* work with MSHTML.
> The thing is, I personally, as well as most users want things *to work*.
> Users don't care how proper the architecture is. With Mozilla ActiveX
> things used to and still does work! But now Wine can't use it, because
> you removed such possibility. What's wrong with having two alternative
> implementation? Let users decide what they want - Picasa, Outlook or Steam.

It will add configure option that we will want to remove anyway.


More information about the wine-devel mailing list