Re: Wine Gecko 1.1.0 RC1
On 9/3/10 10:04 PM, Anssi Hannula wrote: On Monday 23 August 2010 22:00:22 Jacek Caban wrote: This build is based on Firefox 4 beta 4 (that is expected to be released this week). It goes with massive improvements, but it's less interesting here. We finally have sane building procedure. Thanks to mingw-w64 project, we no longer have to maintain our own fixes to headers and libraries. I guess http://wiki.winehq.org/BuildingWineGecko is no longer up-to-date, then? Yeah, the build procedure changes quite often as I was working to make it easier and more proper. Build instructions are stored in Git. It doesn't make much sense to maintain wiki page anymore, so I've changed it to refer to Git. Jacek
Re: Wine Gecko 1.1.0 RC1
On Mon, Aug 23, 2010 at 10:00 PM, Jacek Caban ja...@codeweavers.com wrote: It's not yet fully tested and I need help with this. I'd appreciate any help with testing. Almost all changes required by the new Gecko were possible to be committed to current Wine. The attached patch contains remaining bits. All you need to test it is current Wine Git (must be today's or later), the attached patch and a new Gecko build. You can find new builds [1] and win64 build [2]. Put .cab files according to generic instructions [3] (obviously with different file names due to different Gecko versions). Please let me know of any regressions. There are some recent crashes in urlmon:url (32 bit) that seem to be related to wine gecko. The crashes are pretty random (usually crashes at asynchronous https test, but I've seen crashes with other backtraces or in other tests, and sometimes all tests run without a crash). I don't have the debug symbols for wine-gecko installed, but I attached a log+backtrace of the crash. Tell me if you need something more. They started for me just about when we switched to wine 1.1.0, but I'm not the only one who gets them. The bad thing is that it stops the tests with a message box saying TerminateProcess failed, so it's a pretty bad crash. Octavian $ WINETEST_DEBUG=1 WINEPREFIX=~/.wine32 ./wine programs/winetest/urlmon_test.exe url url.c:2965: test CreateAsyncBindCtx... url.c:2968: test CreateAsyncBindCtxEx... url.c:2971: test RegisterBindStatusCallback... url.c:2973: test BindToStorage failures... err:ole:CoGetClassObject apartment not initialised err:ole:CoGetClassObject apartment not initialised err:ole:CoGetClassObject apartment not initialised url.c:2976: synchronous http test (COM not initialised)... fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! url.c:2981: test StdURLMoniker... url.c:2984: synchronous http test... fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! url.c:2448: Test failed: unexpected OnProgress_FINDINGRESOURCE url.c:2987: emulated synchronous http test (to file)... url.c:2990: synchronous http test (to object)... fixme:urlmon:URLMoniker_BindToObject use running object table fixme:system:SetProcessDPIAware stub! fixme:iphlpapi:NotifyAddrChange (Handle 0x9ce914, overlapped 0x9ce918): stub fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:mshtml:nsURI_GetAsciiHost default action not implemented fixme:mshtml:nsChannel_Open (0x18511b8)-(0x32de04) fixme:mshtml:nsHttpChannelInternal_SetDocumentURI (0x185ae28)-() fixme:wininet:InternetLockRequestFile STUB fixme:mshtml:nsChannel_IsNoStoreResponse (0x185ae28)-(0x32e124) fixme:mshtml:nsChannel_IsNoCacheResponse (0x185ae28)-(0x32e120) fixme:mshtml:nsURI_GetHostPort default action not implemented fixme:mshtml:nsURI_GetHostPort default action not implemented fixme:mshtml:nsURI_GetHost default action not implemented fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:mshtml:nsChannel_IsNoStoreResponse (0x185ae28)-(0x32f4e4) fixme:mshtml:nsChannel_IsNoCacheResponse (0x185ae28)-(0x32f4e0) fixme:mshtml:nsChannel_Cancel (0x185ae28)-(804b0002) url.c:2646: Test failed: unexpected Obj_OnProgress_FINDINGRESOURCE url.c:2993: emulated synchronous http test (with cache)... url.c:2996: emulated synchronous http test (with cache, no read)... url.c:2999: synchronous http test (with cache, no read)... fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! url.c:2448: Test failed: unexpected OnProgress_FINDINGRESOURCE url.c:3002: synchronous file test... url.c:3005: emulated synchronous file test (to file)... url.c:3008: synchronous file test (to object)... fixme:urlmon:URLMoniker_BindToObject use running object table fixme:mshtml:nsURI_GetHostPort default action not implemented fixme:mshtml:nsURI_GetHost default action not implemented fixme:mshtml:nsChannel_Cancel (0x18989c8)-(804b0002) url.c:3013: http test... fixme:mshtml:nsURI_GetHost default action not implemented fixme:mshtml:nsURI_GetHost default action not implemented fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! url.c:2448: Test failed: unexpected OnProgress_FINDINGRESOURCE url.c:3016: http test (to file)... fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! url.c:2448: Test failed: unexpected OnProgress_FINDINGRESOURCE url.c:3019: http test (to object)... fixme:urlmon:URLMoniker_BindToObject use running object table fixme:mshtml:nsURI_GetAsciiHost default action not implemented fixme:mshtml:nsHttpChannelInternal_SetDocumentURI (0x11cbaa8)-() fixme:wininet:InternetLockRequestFile STUB
Re: Wine Gecko 1.1.0 RC1
On 9/4/10 2:28 PM, Octavian Voicu wrote: On Mon, Aug 23, 2010 at 10:00 PM, Jacek Caban ja...@codeweavers.com mailto:ja...@codeweavers.com wrote: It's not yet fully tested and I need help with this. I'd appreciate any help with testing. Almost all changes required by the new Gecko were possible to be committed to current Wine. The attached patch contains remaining bits. All you need to test it is current Wine Git (must be today's or later), the attached patch and a new Gecko build. You can find new builds [1] and win64 build [2]. Put .cab files according to generic instructions [3] (obviously with different file names due to different Gecko versions). Please let me know of any regressions. There are some recent crashes in urlmon:url (32 bit) that seem to be related to wine gecko. The crashes are pretty random (usually crashes at asynchronous https test, but I've seen crashes with other backtraces or in other tests, and sometimes all tests run without a crash). I don't have the debug symbols for wine-gecko installed, but I attached a log+backtrace of the crash. Tell me if you need something more. They started for me just about when we switched to wine 1.1.0, but I'm not the only one who gets them. The bad thing is that it stops the tests with a message box saying TerminateProcess failed, so it's a pretty bad crash This is not new crash. It's an old, rare random crash. I've tried to debug it, but didn't find the bug. I will probably come back to this later, when time permits. Jacek
Re: Wine Gecko 1.1.0 RC1
On Sat, Sep 4, 2010 at 9:00 PM, Jacek Caban ja...@codeweavers.com wrote: On 9/4/10 2:28 PM, Octavian Voicu wrote: There are some recent crashes in urlmon:url (32 bit) that seem to be related to wine gecko. The crashes are pretty random (usually crashes at asynchronous https test, but I've seen crashes with other backtraces or in other tests, and sometimes all tests run without a crash). I don't have the debug symbols for wine-gecko installed, but I attached a log+backtrace of the crash. Tell me if you need something more. They started for me just about when we switched to wine 1.1.0, but I'm not the only one who gets them. The bad thing is that it stops the tests with a message box saying TerminateProcess failed, so it's a pretty bad crash This is not new crash. It's an old, rare random crash. I've tried to debug it, but didn't find the bug. I will probably come back to this later, when time permits. But is it related to a bug in wine or gecko? Running with debug version of gecko shows numerous assertion failures and at the end lots of unclaimed memory, but I suppose you know about these problems. I know it's random, but after the upgrade to wine 1.1.0 it's become must less rare for me. Again, I must stress that that is just one backtrace, I've seen crashes in different places, but most happen somewhere during https test (again, not in the same place all the time).
Re: Wine Gecko 1.1.0 RC1
On 9/4/10 8:09 PM, Octavian Voicu wrote: On Sat, Sep 4, 2010 at 9:00 PM, Jacek Caban ja...@codeweavers.com mailto:ja...@codeweavers.com wrote: On 9/4/10 2:28 PM, Octavian Voicu wrote: There are some recent crashes in urlmon:url (32 bit) that seem to be related to wine gecko. The crashes are pretty random (usually crashes at asynchronous https test, but I've seen crashes with other backtraces or in other tests, and sometimes all tests run without a crash). I don't have the debug symbols for wine-gecko installed, but I attached a log+backtrace of the crash. Tell me if you need something more. They started for me just about when we switched to wine 1.1.0, but I'm not the only one who gets them. The bad thing is that it stops the tests with a message box saying TerminateProcess failed, so it's a pretty bad crash This is not new crash. It's an old, rare random crash. I've tried to debug it, but didn't find the bug. I will probably come back to this later, when time permits. But is it related to a bug in wine or gecko? Running with debug version of gecko shows numerous assertion failures and at the end lots of unclaimed memory, but I suppose you know about these problems. It seems to be a problem in Wine, not Gecko. I've seen memory corruptions in crypt32, although they were not nessessarily crypt32 bugs. I know it's random, but after the upgrade to wine 1.1.0 it's become must less rare for me. Again, I must stress that that is just one backtrace, I've seen crashes in different places, but most happen somewhere during https test (again, not in the same place all the time). Yeah, that's the nature of random bugs. Jacek
Re: Wine Gecko 1.1.0 RC1
On Monday 23 August 2010 22:00:22 Jacek Caban wrote: This build is based on Firefox 4 beta 4 (that is expected to be released this week). It goes with massive improvements, but it's less interesting here. We finally have sane building procedure. Thanks to mingw-w64 project, we no longer have to maintain our own fixes to headers and libraries. I guess http://wiki.winehq.org/BuildingWineGecko is no longer up-to-date, then? Also I've fixed a bug so that moztools is no longer needed for crosscompiling. It means that we no longer need any binary files, which should make open source fanatics (in a good sense) happy. Well... almost. We still need to create .cab file, which I do via Filzip on Windows. That's something we can work around. We use .cab files, because that's the only archive format that Wine can deal with. We can teach Wine to use other formats, which would finally make it possible for Wine packagers to do their own builds, if they like. -- Anssi Hannula
Re: Wine Gecko 1.1.0 RC1
On 24 August 2010 05:00, Jacek Caban ja...@codeweavers.com wrote: The attached patch contains remaining bits. Haven't tested it, but I was having a flick through, and noticed that the second hunk for dlls/mshtml/nsembed.c has: ERR(Could not get nsIDontent interface: %08x\n, nsres); instead of ERR(Could not get nsIContent interface: %08x\n, nsres); -- Paul TBBle Hampson, paul.hamp...@pobox.com
Wine Gecko 1.1.0 RC1
Applied the patch to master, recompiled ok. I put the rc1 cab in
/usr/share/wine/gecko/, as always.
In the creation of a new prefix, it gave me an err which wasn't there
before:
err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057
but 'wine iexplore' works better than before (sites that crashed wine before
don't crash it anymore).
I investigated it a bit recreating a new prefix with 'WINEDEBUG=+mshtml
winecfg' and here's the log:
wine: created the configuration directory '/home/luca/.wine'
trace:mshtml:register_server (1)
trace:mshtml:load_gecko ()
trace:mshtml:install_cab
(LZ:\\usr\\bin\\..\\share\\wine\\gecko\\wine_gecko-1.1.0-rc1-x86.cab)
trace:mshtml:check_version Wine Gecko 1.1.0-rc1
trace:mshtml:load_xpcom
(LC:\\windows\\system32\\gecko\\1.1.0-rc1\\wine_gecko)
fixme:system:SetProcessDPIAware stub!
trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsISupports
0x33d374)
trace:mshtml:nsDirectoryServiceProvider_QueryInterface
(IID_nsIDirectoryServiceProvider 0x33d214)
trace:mshtml:nsDirectoryServiceProvider_GetFile (GreD 0x33d2ec 0x33d2e8)
trace:mshtml:nsDirectoryServiceProvider_QueryInterface
(IID_nsIDirectoryServiceProvider 0x33d214)
trace:mshtml:nsDirectoryServiceProvider_GetFile (XCurProcD 0x33d2ec
0x33d2e8)
trace:mshtml:nsDirectoryServiceProvider_QueryInterface
(IID_nsIDirectoryServiceProvider 0x33bfc4)
trace:mshtml:nsDirectoryServiceProvider_GetFile (PrfDef 0x33c09c 0x33c098)
warn:mshtml:nsDirectoryServiceProvider_QueryInterface
({2f977d4b-5485-11d4-87e2-0010a4e75ef2} 0x33bff4)
warn:mshtml:nsDirectoryServiceProvider_QueryInterface
({2f977d4b-5485-11d4-87e2-0010a4e75ef2} 0x33bff4)
fixme:iphlpapi:NotifyAddrChange (Handle 0xf5e914, overlapped 0xf5e918): stub
trace:mshtml:nsDirectoryServiceProvider_QueryInterface
(IID_nsIDirectoryServiceProvider 0x33bc64)
trace:mshtml:nsDirectoryServiceProvider_GetFile (AChrom 0x33bd3c 0x33bd38)
err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057
trace:mshtml:nsIOService_GetProtocolHandler (file 0x33cff8)
trace:mshtml:nsIOService_NewURI
(file:///C:/windows/system32/gecko/1.1.0-rc1/wine_gecko/components/nsTryToClose.js
(null) (nil) 0x33d15c)
trace:mshtml:nsDirectoryServiceProvider_QueryInterface
(IID_nsIDirectoryServiceProvider 0x33ccb4)
trace:mshtml:nsDirectoryServiceProvider_GetFile (ProfDS 0x33cd8c 0x33cd88)
trace:mshtml:nsDirectoryServiceProvider_QueryInterface
(IID_nsIDirectoryServiceProvider 0x33ccb4)
trace:mshtml:nsDirectoryServiceProvider_GetFile (ProfD 0x33cd8c 0x33cd88)
trace:mshtml:nsDirectoryServiceProvider_QueryInterface
(IID_nsIDirectoryServiceProvider 0x33ccb4)
trace:mshtml:nsDirectoryServiceProvider_GetFile (ProfLDS 0x33cd8c
0x33cd88)
trace:mshtml:nsDirectoryServiceProvider_QueryInterface
(IID_nsIDirectoryServiceProvider 0x33ccb4)
trace:mshtml:nsDirectoryServiceProvider_GetFile (ProfLD 0x33cd8c 0x33cd88)
trace:mshtml:nsIOService_NewURI (resource://gre/modules/XPCOMUtils.jsm
(null) (nil) 0x33acb8)
trace:mshtml:nsDirectoryServiceProvider_QueryInterface
(IID_nsIDirectoryServiceProvider 0x33851c)
trace:mshtml:nsDirectoryServiceProvider_GetFile (CurProcD 0x3385f4
0x3385f0)
trace:mshtml:nsIOService_NewFileURI (0x7613b8 0x338674)
trace:mshtml:nsIOService_NewFileURI (0x7613b8 0x338674)
trace:mshtml:nsIOService_NewURI (jar:chrome/toolkit.jar!/res/ (null)
0x75f6c8 0x3386e4)
trace:mshtml:nsIOService_ExtractScheme (jar:chrome/toolkit.jar!/res/
0x3363d0)
trace:mshtml:nsIOService_NewURI (chrome/toolkit.jar!/res/ 0x75f6c8
0x7613cc)
trace:mshtml:nsIOService_NewURI not wraping
trace:mshtml:nsIOService_NewChannelFromURI (0x75fa90 0x33acb4)
trace:mshtml:nsIOService_NewChannelFromURI Could not get nsWineURI: 80004002
trace:mshtml:nsIOService_NewChannel
(file:///C:/windows/system32/gecko/1.1.0-rc1/wine_gecko/modules/XPCOMUtils.jsm
(null) (nil) 0x33acb4)
trace:mshtml:close_gecko ()
wine: configuration in '/home/luca/.wine' has been updated.
Hope it helps :)
Re: Wine Gecko 1.1.0 RC1
On 8/24/10 12:12 PM, Luca Bennati wrote: Applied the patch to master, recompiled ok. I put the rc1 cab in /usr/share/wine/gecko/, as always. In the creation of a new prefix, it gave me an err which wasn't there before: err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057 but 'wine iexplore' works better than before (sites that crashed wine before don't crash it anymore). I investigated it a bit recreating a new prefix with 'WINEDEBUG=+mshtml winecfg' and here's the log: Thanks for testing. This error is a known false error. Modules loading method has changed in Gecko and AutoRegister call is no longer needed, so I'm going to remove this call. It's harmless in the new Gecko, so I'm going to do it in another patch to limit size of this one. Thanks, Jacek
Wine Gecko 1.1.0 RC1
HI all,
(If you're not interested in details, please read the last paragraph).
It's been over year since the last Gecko update. A lot has happen since
then. I've been planning to update our build a bit later, with Firefox 4
codebase, but plans have changed. We had some serious problems with
previous build (like bug 22157 and bug 24059, both should be fixed in the
new build). Also there is *a lot* happening in Mozilla world. With upcoming
Firefox 4, the backward compatibility is no longer supported and the code
is changing with an impressive speed. I try to follow these changes, but I
need a good solid base so that I can take care of our needs in Mozilla.
This build is based on Firefox 4 beta 4 (that is expected to be released
this week). It goes with massive improvements, but it's less interesting
here. We finally have sane building procedure. Thanks to mingw-w64 project,
we no longer have to maintain our own fixes to headers and libraries. Also
I've fixed a bug so that moztools is no longer needed for crosscompiling.
It means that we no longer need any binary files, which should make open
source fanatics (in a good sense) happy. Well... almost. We still need to
create .cab file, which I do via Filzip on Windows. That's something we can
work around. We use .cab files, because that's the only archive format that
Wine can deal with. We can teach Wine to use other formats, which would
finally make it possible for Wine packagers to do their own builds, if they
like.
The new Gecko is also the first to support Win64. Not all tests pass yet,
but failing ones are due to missing DispCallFunc implementation for Win64,
so it's not a Gecko problem.
It's not yet fully tested and I need help with this. I'd appreciate any
help with testing. Almost all changes required by the new Gecko were
possible to be committed to current Wine. The attached patch contains
remaining bits. All you need to test it is current Wine Git (must be
today's or later), the attached patch and a new Gecko build. You can find
new builds [1] and win64 build [2]. Put .cab files according to generic
instructions [3] (obviously with different file names due to different
Gecko versions). Please let me know of any regressions.
Thanks,
Jacek
[1] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86.cab
[2] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86_64.cab
[3] http://wiki.winehq.org/Gecko
diff --git a/dlls/mshtml/install.c b/dlls/mshtml/install.c
index 65faa5a..1079713 100644
--- a/dlls/mshtml/install.c
+++ b/dlls/mshtml/install.c
@@ -49,6 +49,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(mshtml);
#ifdef __i386__
#define GECKO_ARCH x86
+#elif defined(__x86_64__)
+#define GECKO_ARCH x86_64
#else
#define GECKO_ARCH
#endif
diff --git a/dlls/mshtml/mutation.c b/dlls/mshtml/mutation.c
index edcb2cc..efc9db8 100644
--- a/dlls/mshtml/mutation.c
+++ b/dlls/mshtml/mutation.c
@@ -498,12 +498,12 @@ static void NSAPI
nsDocumentObserver_AttributeWillChange(nsIDocumentObserver *if
}
static void NSAPI nsDocumentObserver_AttributeChanged(nsIDocumentObserver
*iface, nsIDocument *aDocument,
-nsIContent *aContent, PRInt32 aNameSpaceID, nsIAtom *aAttribute,
PRInt32 aModType, PRUint32 aStateMask)
+nsIContent *aContent, PRInt32 aNameSpaceID, nsIAtom *aAttribute,
PRInt32 aModType)
{
}
static void NSAPI nsDocumentObserver_ContentAppended(nsIDocumentObserver
*iface, nsIDocument *aDocument,
-nsIContent *aContainer, PRInt32 aNewIndexInContainer)
+nsIContent *aContainer, nsIContent *aFirstNewContent, PRInt32
aNewIndexInContainer)
{
}
@@ -513,7 +513,8 @@ static void NSAPI
nsDocumentObserver_ContentInserted(nsIDocumentObserver *iface,
}
static void NSAPI nsDocumentObserver_ContentRemoved(nsIDocumentObserver
*iface, nsIDocument *aDocument,
-nsIContent *aContainer, nsIContent *aChild, PRInt32 aIndexInContainer)
+nsIContent *aContainer, nsIContent *aChild, PRInt32 aIndexInContainer,
+nsIContent *aProviousSibling)
{
}
@@ -557,6 +558,11 @@ static void NSAPI
nsDocumentObserver_ContentStatesChanged(nsIDocumentObserver *i
{
}
+static void NSAPI nsDocumentObserver_DocumentStatesChanged(nsIDocumentObserver
*iface, nsIDocument *aDocument,
+PRInt32 aStateMask)
+{
+}
+
static void NSAPI nsDocumentObserver_StyleSheetAdded(nsIDocumentObserver
*iface, nsIDocument *aDocument,
nsIStyleSheet *aStyleSheet, PRBool aDocumentSheet)
{
@@ -668,6 +674,7 @@ static const nsIDocumentObserverVtbl nsDocumentObserverVtbl
= {
nsDocumentObserver_BeginLoad,
nsDocumentObserver_EndLoad,
nsDocumentObserver_ContentStatesChanged,
+nsDocumentObserver_DocumentStatesChanged,
nsDocumentObserver_StyleSheetAdded,
nsDocumentObserver_StyleSheetRemoved,
nsDocumentObserver_StyleSheetApplicableStateChanged,
diff --git a/dlls/mshtml/nsembed.c b/dlls/mshtml/nsembed.c
index 8ea99a2..efc129b 100644
--- a/dlls/mshtml/nsembed.c
+++
