New Gecko package

[Jacek Caban]

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
bugzilla.
> 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.


Jacek