[webkit-dev] Fix for Qt build

2007-05-12 Thread Maciej Stachowiak


I can't check this in right now because the SVN server is temporarily  
out of disk, but this appears to mostly fix the Qt build, at least in  
QtLauncher. Rob Buis helped me test and is running layout tests now.


Index: WebKitQt/ChangeLog
===
--- WebKitQt/ChangeLog  (revision 21427)
+++ WebKitQt/ChangeLog  (working copy)
@@ -1,3 +1,14 @@
+2007-05-12  Maciej Stachowiak  [EMAIL PROTECTED]
+
+Reviewed by Rob Buis.
+
+- call Frame::init as needed - this prevents crashes but  
pages don't appear.

+
+* Api/qwebframe.cpp:
+(QWebFramePrivate::init):
+* WebKitPart/WebKitPart.cpp:
+(WebKitPart::initView):
+
2007-05-08  Steve Falkenburg  [EMAIL PROTECTED]
 Reviewed by Ada.
Index: WebKitQt/Api/qwebframe.cpp
===
--- WebKitQt/Api/qwebframe.cpp  (revision 21427)
+++ WebKitQt/Api/qwebframe.cpp  (working copy)
@@ -79,6 +79,7 @@
 frameView-setScrollArea(qframe);
 frameView-setAllowsScrolling(frameData-allowsScrolling);
 frame-setView(frameView.get());
+frame-init();
 eventHandler = frame-eventHandler();
}
Index: WebKitQt/WebKitPart/WebKitPart.cpp
===
--- WebKitQt/WebKitPart/WebKitPart.cpp  (revision 21427)
+++ WebKitQt/WebKitPart/WebKitPart.cpp  (working copy)
@@ -123,6 +123,8 @@
 m_frame-setView(frameView);
 m_frameView-setParentWidget(parentWidget);
+m_frame-init();
+
 // Initialize KParts widget...
 setWidget(m_frame-view()-qwidget());
}

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Fix for Qt build

2007-05-12 Thread Holger Freyther


Am 12.05.2007 um 12:32 schrieb Maciej Stachowiak:



I can't check this in right now because the SVN server is  
temporarily out of disk, but this appears to mostly fix the Qt  
build, at least in QtLauncher. Rob Buis helped me test and is  
running layout tests now.


Hey,
so the Gdk port remains and I'm a bit lost and won't have time before  
monday. At least the Frame::init is the obvious change but I see a  
crash on the google site. It is reproducable by starting the  
GdkLauncher and clicking on any link. What confuses me is that in the  
below backtrace there is no way that FrameLoaderClientGdk can call  
setEncoding. I don't know the relation between ResourceLoader,  
FrameLoader, MainResourceLoader, DocumentLoader and  
ResourceHandleManager yet so I don't know who should call into the  
FrameLoaderClient and when.


From yesterday's research I saw that platform//network/gdk is rather  
incomplete, so it might be partly to blame. What I see is that  
directly from curl callback didReceiveData gets called and gets  
delivered up to the FrameLoader without ever calling into  
FrameLoaderClient or I forgot to set a breakpoint and missed a  
position where I can/should call setEncoding from.


What I will look into on Monday is:
-Where and when is the document of the Frame gets destroyed
	-What is the platform/network code omitting. I know of not handling  
HTTP response headers at all.
	-See if any unimplemented method of the FrameLoaderClientGdk gets  
called (Currently it looks like   
WebCore::FrameLoaderClientGdk::canCachePage() is the only one)




--- a/WebKitTools/GdkLauncher/main.cpp
+++ b/WebKitTools/GdkLauncher/main.cpp
@@ -213,6 +213,7 @@ int main(int argc, char* argv[])
 gFrame-setView(frameView);
 frameView-ScrollView::setDrawable(frameWindow-window);
+gFrame-init();
 gFrame-loader()-load(ResourceRequest(url));
 gtk_main();
#if 0 // FIXME: this crashes at the moment. needs to provide DragClient





0xb7a6d598 in WebCore::FrameLoader::saveDocumentState  
(this=0x8199630) at ../../../WebCore/loader/FrameLoader.cpp:3755

3755ASSERT(document);
(gdb) bt
#0  0xb7a6d598 in WebCore::FrameLoader::saveDocumentState  
(this=0x8199630) at ../../../WebCore/loader/FrameLoader.cpp:3755
#1  0xb7a7d283 in WebCore::FrameLoader::closeURL (this=0x8199630)  
at ../../../WebCore/loader/FrameLoader.cpp:627
#2  0xb7a7dea8 in WebCore::FrameLoader::transitionToCommitted  
(this=0x8199630, [EMAIL PROTECTED]) at ../../../WebCore/loader/ 
FrameLoader.cpp:2401
#3  0xb7a7ea50 in WebCore::FrameLoader::commitProvisionalLoad  
(this=0x8199630, [EMAIL PROTECTED]) at ../../../WebCore/ 
loader/FrameLoader.cpp:2359
#4  0xb7a64201 in WebCore::DocumentLoader::commitIfReady  
(this=0x8236e90) at ../../../WebCore/loader/DocumentLoader.cpp:305

#5  0xb7a64c6e in WebCore::DocumentLoader::commitLoad (this=0x8236e90,
data=0x824510b htmlheadmeta http-equiv=\content-type\  
content=\text/html; charset=ISO-8859-1\titleGoogle/ 
titlestyle!--\nbody,td,a,p,.h{font-family:arial,sans-serif}\n.h 
{font-size:20px}\n.h{color:#3366cc}\n, length=1255) at ../../../ 
WebCore/loader/DocumentLoader.cpp:345

#6  0xb7a64d2e in WebCore::DocumentLoader::receivedData (this=0x8236e90,
data=0x824510b htmlheadmeta http-equiv=\content-type\  
content=\text/html; charset=ISO-8859-1\titleGoogle/ 
titlestyle!--\nbody,td,a,p,.h{font-family:arial,sans-serif}\n.h 
{font-size:20px}\n.h{color:#3366cc}\n, length=1255) at ../../../ 
WebCore/loader/DocumentLoader.cpp:359

#7  0xb7a73117 in WebCore::FrameLoader::receivedData (this=0x8199630,
data=0x824510b htmlheadmeta http-equiv=\content-type\  
content=\text/html; charset=ISO-8859-1\titleGoogle/ 
titlestyle!--\nbody,td,a,p,.h{font-family:arial,sans-serif}\n.h 
{font-size:20px}\n.h{color:#3366cc}\n, length=1255) at ../../../ 
WebCore/loader/FrameLoader.cpp:2052

#8  0xb7a9ac24 in WebCore::MainResourceLoader::addData (this=0x822e9d0,
data=0x824510b htmlheadmeta http-equiv=\content-type\  
content=\text/html; charset=ISO-8859-1\titleGoogle/ 
titlestyle!--\nbody,td,a,p,.h{font-family:arial,sans-serif}\n.h 
{font-size:20px}\n.h{color:#3366cc}\n, length=1255,  
allAtOnce=false) at ../../../WebCore/loader/MainResourceLoader.cpp:136
#9  0xb7aa11d7 in WebCore::ResourceLoader::didReceiveData  
(this=0x822e9d0,
data=0x824510b htmlheadmeta http-equiv=\content-type\  
content=\text/html; charset=ISO-8859-1\titleGoogle/ 
titlestyle!--\nbody,td,a,p,.h{font-family:arial,sans-serif}\n.h 
{font-size:20px}\n.h{color:#3366cc}\n, length=1255,  
lengthReceived=0, allAtOnce=false) at ../../../WebCore/loader/ 
ResourceLoader.cpp:208
#10 0xb7a9a99e in WebCore::MainResourceLoader::didReceiveData  
(this=0x822e9d0,
data=0x824510b htmlheadmeta http-equiv=\content-type\  
content=\text/html; charset=ISO-8859-1\titleGoogle/ 
titlestyle!--\nbody,td,a,p,.h{font-family:arial,sans-serif}\n.h 
{font-size:20px}\n.h{color:#3366cc}\n, length=1255,  
lengthReceived=0, 

Re: [webkit-dev] Fix for Qt build

2007-05-12 Thread Holger Freyther


Am 12.05.2007 um 13:28 schrieb Holger Freyther:



Am 12.05.2007 um 12:32 schrieb Maciej Stachowiak:



I can't check this in right now because the SVN server is  
temporarily out of disk, but this appears to mostly fix the Qt  
build, at least in QtLauncher. Rob Buis helped me test and is  
running layout tests now.




Okay,
the difference between Mac and Gdk is in  
FrameLoaderClient::canCachePage. If canCachePage returns false, clear 
() will be called which sets m_frame-d-m_doc-m_ptr to 0. And on  
load setEncoding comes after calling saveDocumentState. So there is  
no way to restore/has a valid document.


I don't know how to fix it, but at least this explains why it crashes  
on Gdk and not on Mac. I think we should review codepath's ending in  
a clear().




void FrameLoader::provisionalLoadStarted()
{
m_firstLayoutDone = false;
cancelRedirection(true);
m_client-provisionalLoadStarted();

if (canCachePage()) {
if (m_client-canCachePage()) {
if (!m_currentHistoryItem-cachedPage()) {
cachePageToHistoryItem(m_currentHistoryItem.get());
purgePageCache();
}
} else {
// Put the document into a null state, so it can be  
restored correctly.·

clear();
}
}
}

PS: Now I can finally return to my text 
book___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Fix for Qt build

2007-05-12 Thread Maciej Stachowiak


On May 12, 2007, at 7:59 AM, Holger Freyther wrote:



Am 12.05.2007 um 13:28 schrieb Holger Freyther:



Am 12.05.2007 um 12:32 schrieb Maciej Stachowiak:



I can't check this in right now because the SVN server is  
temporarily out of disk, but this appears to mostly fix the Qt  
build, at least in QtLauncher. Rob Buis helped me test and is  
running layout tests now.




Okay,
the difference between Mac and Gdk is in  
FrameLoaderClient::canCachePage. If canCachePage returns false,  
clear() will be called which sets m_frame-d-m_doc-m_ptr to 0.  
And on load setEncoding comes after calling saveDocumentState. So  
there is no way to restore/has a valid document.


Oh - that was actually a bug and I believe I've landed a fix.


I don't know how to fix it, but at least this explains why it  
crashes on Gdk and not on Mac. I think we should review codepath's  
ending in a clear().


void FrameLoader::provisionalLoadStarted()
{
m_firstLayoutDone = false;
cancelRedirection(true);
m_client-provisionalLoadStarted();

if (canCachePage()) {
if (m_client-canCachePage()) {
if (!m_currentHistoryItem-cachedPage()) {
cachePageToHistoryItem(m_currentHistoryItem.get());
purgePageCache();
}
} else {
// Put the document into a null state, so it can be  
restored correctly.·

clear();
}
}
}


The code now reads like this:

if (canCachePage()  m_client-canCachePage()  ! 
m_currentHistoryItem-cachedPage()) {

cachePageToHistoryItem(m_currentHistoryItem.get());
purgePageCache();
}


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev