Re: [webkit-dev] HitTest'ing scrollbars
Hi, just sharing a few words from hyatt on IRC: May 17 00:07:00 dhyattyeah your analysis is right May 17 00:08:34 dhyattthat RenderLayer comment is about dragging the map in google maps May 17 00:08:41 dhyattso that would be the thing to test to make sure it doesn't break May 17 00:09:47 dhyatttonikitoo: but yeah it's weird May 17 00:10:25 tonikitoo dhyatt, I am think is more inconsistent is the fact that we fired mousedown, but do not fire click or mouseup May 17 00:10:41 tonikitoo while firefox, for example, fires the first and the later May 17 00:10:41 dhyattyeah, i don't really have strong opinions other than don't break the web please :) On Sun, May 9, 2010 at 11:07 PM, Darin Adler da...@apple.com wrote: I think your analysis is right, but I’m not sure. Hyatt did a lot of the scrollbar work for Windows that was later imitated on the other platforms. Maybe he can comment on this? -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Help with reviewing Spatial Navigation patches
Hi,
As part of my (spare-time) effort to keep developing the Spatial
Navigation [1], I've been getting great reviewing support from Simon
Fraser and Kenneth Christiansen, but lately the number of pending
review patches increased a bit. There are on my plate patches from
polishment work to real bug fixes and feature completeness. So there
some very easy patches to review, like:
-polishment work:
* bug 38584 - Spatial Navigation: use data url in layout
* bug 38488 - Spatial Navigation: create a getter for the fudgeFactor
* bug 37633 - Spatial Navigation: use a static var in maxDistance
method ( SpatialNavigation.h ) -- one liner!
- improvements on the feature test covarege:
* bug 38585 - Spatial Navigation: add a layout test which runs with
Frame Flattening ON
- preparation for feature implementation:
* bug 37803 - Spatial Navigation: adapt the logic of
{deep}findFocusableNodeInDirection to do traversal starting from Node*
not Document*
For this one I even added a comment in the bug with a detailed
explaination about the changes [2], so a reviewer does not need to
know the feature code in deep to review it.
* Spatial Navigation: refactor hasOffscreenRect to work with
scrollable content -- has a patch , but not set r? because it depends
on bug 36463, which depends on 37803.
... as well as not so trivial patches to be reviewed:
- feature implementation:
* bug 36463 - Spatial Navigation: make it work with focusable
elements in overflow content -- depends on the former preparation bug
* bug 37153 - Spatial Navigation: add support to input type=text
and textarea -- has a patch, but needs polishment to request
review.
Reviewers, could you please help with that?
Thank you in advance
[1] https://bugs.webkit.org/showdependencytree.cgi?id=18662hide_resolved=0
[2] https://bugs.webkit.org/show_bug.cgi?id=37803#c5
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with reviewing Spatial Navigation patches
- preparation for feature implementation:
* bug 37803 - Spatial Navigation: adapt the logic of
{deep}findFocusableNodeInDirection to do traversal starting from Node*
not Document*
For this one I even added a comment in the bug with a detailed
explaination about the changes [2], so a reviewer does not need to
know the feature code in deep to review it.
* Spatial Navigation: refactor hasOffscreenRect to work with
scrollable content -- has a patch , but not set r? because it depends
on bug 36463, which depends on 37803.
... I forgot to write: that is bug 38590.
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] HitTest'ing scrollbars
Hi.
While working on bug 16809 (Clicking a scrollbar blurs the currently
focused element), a couple of questions raised about the current
behavior of mouse clicks on scrollbars.
On ports that do *not* use platform/native widgets for rendering
scrollbars (including Qt, Windows, Chromium):
1) clicking on a frame scrollbar will hitTest WebCore at the position
of this main frame scrollbar but won't set HitTest::scrollbar, while
hitTest'ing an in-frame scrollbar (e.g. a scrollbar of a scrollbable
div) does set it. Is this behavior by design?
Due to that, snippets like the following are needed in certain cases:
EventHandler::handleMousePressEvent(PlatformMouseEvent)
{
(...)
FrameView* view = m_frame-view();
Scrollbar* scrollbar = view ?
view-scrollbarAtPoint(mouseEvent.pos()) : 0;
if (!scrollbar)
scrollbar = mev.scrollbar();
(...)
}
It seems strange that we have to rely on scrollbarAtPoint of FrameView
and fallback to HitTest::scrollbar . Maybe the former should not be
necessary if HitTest::scrollbar got set properly.
2) Clicking on main frame scrollbars will set HTML as
HitTest::targetNode . This seems like an intentional behavior
according to the comment in the snippet below:
bool RenderLayer::hitTest(const HitTestRequest request, HitTestResult result)
{
(...)
RenderLayer* insideLayer = hitTestLayer(this, 0, request, result, boundsRect,
result.point(), false);
if (!insideLayer) {
// We didn't hit any layer. If we are the root
// layer and the mouse is -- or just was -- down,
// return ourselves. We do this so mouse events
// continue getting delivered after a drag has
// exited the WebView, and so hit testing over
// a scrollbar hits the content document.
if ((request.active() || request.mouseUp()) renderer()-isRenderView())
{
renderer()-updateHitTestResult(result, result.point());
insideLayer = this;
}
}
(...)
But due to that, some side effects like [1] shows up. I would like
to confirm if this is also an intentional behavior before marking bugs
as INVALID or WONTFIX.
3) HitTest'ing a frame scrollbar bar will dispatch, MouseDown event,
but not MousePress and MouseUp. It seems different from what other
vendors do currently (run this testcase in various browsers [2],
including not webkit based ones). Why this behaviour?
[1] https://bugs.webkit.org/show_bug.cgi?id=29484 ([Qt] Clicking on
the frame's scrollbar trigger a click event in the page.)
[2] https://bugs.webkit.org/attachment.cgi?id=20748
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit
Hi, Eventually, I'd like to make --squash the default, but I want this to bake and get some usage before flipping that switch. But I don't think this makes sense as a default to me. But maybe I use git differently than everyone else… I don't do the whole branch-per-bug business. I usually have one git commit per commit I plan to push to SVN (each with a separate ChangeLog entry). I am also on the same boat, so I do not thing --squash should be the default. it would be against the current resulting action of git push, git svn dcommit and svn commit. Apart from that, great work! -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currentTime() and UTC time
I agree with the fact that it should not rely on currentTime() as it currently does. It is probably the root of bugs like https://bugs.webkit.org/show_bug.cgi?id=31550 and many others. On Fri, Apr 16, 2010 at 11:50 AM, Yong Li yong.li.web...@gmail.com wrote: Hi All The default implementation of JS Date is calling currentTime() (by jsCurrentTime()), so it assumes currentTime() returns current UTC time, and system UTC time can be changed. However, currentTime() is also used in most cases as a system tick count, which means it should always be monotonically increasing. I guess we should remove the dependency on currentTime() from JS Date to fix the confliction. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Gtk debug bots (32 / 64 bit) are out of space
clean up needed! http://build.webkit.org/builders/GTK%20Linux%2032-bit%20Debug/builds/4614/steps/compile-webkit/logs/stdio (...) DerivedSources/JSSVGZoomEvent.lo DerivedSources/JSWebSocket.lo /bin/mkdir -p ./.deps/DerivedSources ranlib: .libs/libWebCoreJS.a: No space left on device make[1]: *** [libWebCoreJS.la] Error 1 make[1]: Leaving directory `/home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Debug' -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about WML support
Hi
It sounds like a bug. Please file one in bugs.webkit.org , preferable
with test case and detailed steps to reproduce, specifying also which
port and platform are you running.
2010/3/23 巴丁-Partin xyts...@gmail.com:
Is that anyone working with WML in webkit?
I use webkit to open the wml page, meet a fata error.
In file:WebCore\rendering\RenderTextControlSingleLine.cpp,the
inputElement() return NULL value,that cause
inputElement()-isSearchField() access memory error.
I trace into InputElement.cpp, find that in
toInputElement():element-hasTagName(WMLNames::inputTag),the hasTagName()
return false.
Related wml code is:
input type=text name=search_phone emptyok=true value= /
And the current node(element) is input.
Folloing is the call tack:
WebCore::RenderTextControlSingleLine::createSubtreeIfNeeded() Line443 +
0x14 Bytes C++
WebCore::RenderTextControlSingleLine::updateFromElement() Line473 C++
WebCore::WMLInputElement::attach() Line236 + 0x26 Bytes C++
WebCore::XMLTokenizer::startElementNs(const unsigned char *
xmlLocalName=0x0be22a83, const unsigned char * xmlPrefix=0x, const
unsigned char * xmlURI=0x, int nb_namespaces=0, const unsigned char
* * libxmlNamespaces=0x, int nb_attributes=4, int nb_defaulted=0,
const unsigned char * * libxmlAttributes=0x0be23ed0) Line766 + 0x26 Bytes
C++
WebCore::startElementNsHandler(void * closure=0x0bdabc48, const unsigned
char * localname=0x0be22a83, const unsigned char * prefix=0x, const
unsigned char * uri=0x, int nb_namespaces=0, const unsigned char * *
namespaces=0x, int nb_attributes=4, int nb_defaulted=0, const
unsigned char * * libxmlAttributes=0x0be23ed0) Line1001 C++
xmlParseStartTag2(_xmlParserCtxt * ctxt=0x0bdabc48, const unsigned char * *
pref=0x0eb3d5d8, const unsigned char * * URI=0x0eb3d5cc, int *
tlen=0x0eb3d650) Line9002 + 0x37 Bytes C
xmlParseTryOrFinish(_xmlParserCtxt * ctxt=0x0bdabc48, int terminate=0)
Line10714 + 0x1b Bytes C
xmlParseChunk(_xmlParserCtxt * ctxt=0x0bdabc48, const char *
chunk=0x18a2b5ca, int size=2614, int terminate=0) Line11446 + 0xd Bytes C
WebCore::XMLTokenizer::doWrite(const WebCore::String parseString={...})
Line628 + 0x22 Bytes C++
WebCore::XMLTokenizer::write(const WebCore::SegmentedString s={...}, bool
__formal=true) Line107 + 0x18 Bytes C++
WebCore::FrameLoader::write(const char * str=0x0be108db, int len=1419, bool
flush=false) Line1035 + 0x27 Bytes C++
WebCore::FrameLoader::addData(const char * bytes=0x0be108db, int
length=1419) Line1824 C++
WebKit::FrameLoaderClient::committedLoad(WebCore::DocumentLoader *
loader=0x187fab80, const char * data=0x0be108db, int length=1419) Line205
C++
WebCore::FrameLoader::committedLoad(WebCore::DocumentLoader *
loader=0x187fab80, const char * data=0x0be108db, int length=1419) Line3626
+ 0x26 Bytes C++
WebCore::DocumentLoader::commitLoad(const char * data=0x0be108db, int
length=1419) Line363 C++
WebCore::DocumentLoader::receivedData(const char * data=0x0be108db, int
length=1419) Line375 C++
WebCore::FrameLoader::receivedData(const char * data=0x0be108db, int
length=1419) Line2429 C++
WebCore::MainResourceLoader::addData(const char * data=0x0be108db, int
length=1419, bool allAtOnce=false) Line149 C++
WebCore::ResourceLoader::didReceiveData(const char * data=0x0be108db, int
length=1419, __int64 lengthReceived=0, bool allAtOnce=false) Line257 + 0x1c
Bytes C++
WebCore::MainResourceLoader::didReceiveData(const char * data=0x0be108db,
int length=1419, __int64 lengthReceived=0, bool allAtOnce=false) Line351
C++
WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle *
__formal=0x18850ff0, const char * data=0x0be108db, int length=1419, int
lengthReceived=0) Line411 + 0x1f Bytes C++
WebCore::writeCallback(void * ptr=0x0be108db, unsigned int size=1, unsigned
int nmemb=1419, void * data=0x18850ff0) Line144 + 0x31 Bytes C++
Curl_client_write(connectdata * conn=0x0bda7848, int type=1, char *
ptr=0x0be108db, unsigned int len=1419) Line418 + 0x21 Bytes C
readwrite_data(SessionHandle * data=0x0be10310, connectdata *
conn=0x0bda7848, SingleRequest * k=0x0be10324, int * didwhat=0x0eb3ea58,
char * done=0x0eb3ebc3) Line690 + 0x16 Bytes C
Curl_readwrite(connectdata * conn=0x0bda7848, char * done=0x0eb3ebc3)
Line1683 + 0x19 Bytes C
multi_runsingle(Curl_multi * multi=0x0bd89860, Curl_one_easy *
easy=0x0bda5230) Line1298 + 0x10 Bytes C
curl_multi_perform(void * multi_handle=0x0bd89860, int *
running_handles=0x0eb3ee98) Line1516 + 0xd Bytes C
WebCore::ResourceHandleManager::downloadTimerCallback(WebCore::TimerWebCore::ResourceHandleManager
* timer=0x16d2fec0) Line302 + 0x13 Bytes C++
WebCore::TimerWebCore::ResourceHandleManager::fired() Line93 + 0x37 Bytes
C++
WebCore::ThreadTimers::fireTimers(double fireTime=1269398709.1910868, const
WTF::VectorWebCore::TimerBase *,0 firingTimers={...}) Line113 + 0xf
Bytes C++
[webkit-dev] AbsoluteClippedOverflowRect return empty IntRect
Hey all. I am facing a strange issue while trying to the get repaintable rect of a given Node* object. In my code I am doing something like: (...) ASSERT(node); node-renderer()-absoluteClippedOverflowRect(); (...) , where node is a valid reference to an a in the following simple html sample in http://pastebin.ca/1850582 (see id=it). In the sample, node is an offscreen anchor in a scrollable div, and calling absoluteClippedOverflowRect returns an empty IntRect to me. If I scroll until it (the node whose id is it) gets visible, and then trigger my snippet code above it returns a valid value. Also, by doing static_castElement*(node)-getRect() I get the same valid rect returned. I am wondering if it is an expected behavior or a bug? Regards -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] AbsoluteClippedOverflowRect return empty IntRect
Hi Simon. That was my thought. Thank you for confirming. On Tue, Mar 23, 2010 at 2:54 PM, Simon Fraser simon.fra...@apple.com wrote: On Mar 23, 2010, at 11:38 AM, tonikitoo (Antonio Gomes) wrote: Hey all. I am facing a strange issue while trying to the get repaintable rect of a given Node* object. In my code I am doing something like: (...) ASSERT(node); node-renderer()-absoluteClippedOverflowRect(); (...) , where node is a valid reference to an a in the following simple html sample in http://pastebin.ca/1850582 (see id=it). In the sample, node is an offscreen anchor in a scrollable div, and calling absoluteClippedOverflowRect returns an empty IntRect to me. If I scroll until it (the node whose id is it) gets visible, and then trigger my snippet code above it returns a valid value. Also, by doing static_castElement*(node)-getRect() I get the same valid rect returned. I am wondering if it is an expected behavior or a bug? Given the clipped in the name of absoluteClippedOverflowRect(), this is expected behavior. absoluteClippedOverflowRect() is used for repainting, and there's no point repainting something that is scrolled out of view. Simon -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Gtk and Qt bots need love
Hey, these 42 missing results files on Qt are there for a while, indeed. I am also trying Kenneth and Ossy w/ the crashy Qt bot, by looking at fast/media/print-restores-previous-mediatype.html On Fri, Mar 19, 2010 at 3:41 PM, Xan Lopez x...@gnome.org wrote: On Fri, Mar 19, 2010 at 9:59 PM, Eric Seidel e...@webkit.org wrote: Gtk and Qt bots need love. Looks like Gtk needs 5 new results, and Qt needs 42. Various other tests are failing there too. Do any Qt/Gtk folks have a minute to try and green up the bots so we can start tracking regressions on those platforms again? Looking at the GTK bots. Xan -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git fetch failing, possible repository corruption
See this: https://bugs.webkit.org/show_bug.cgi?id=36193 On Thu, Mar 18, 2010 at 1:25 PM, Jens Alfke s...@chromium.org wrote: This morning, whenever I try to pull from webkit's git repo I get the following scary error: remote: error: failed to unpack compressed delta at offset 167772124 from ./objects/pack/pack-48166dba7808af6c8cbc7b74dada2c456e2ba411.pack remote: error: failed to read object be61563cc282b7c036d656ec05df6d5d66be4be7 at offset 167772121 from ./objects/pack/pack-48166dba7808af6c8cbc7b74dada2c456e2ba411.pack remote: fatal: object be61563cc282b7c036d656ec05df6d5d66be4be7 is corrupted remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header The only recent post about git I've seen is git.webkit.org is missing svn revision r49890, which doesn't seem related. (Looking at the output closely, I'm now wondering if the double appearance of 'remote' (remote: aborting due to possible repository corruption on the remote side) means the warning is about my _local_ repo?) —Jens ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] qt-ews down for a while
Adam, qt 4.5 support in WebKit trunk is about to be dropped ((or even already dropped). See comment from Benjamin Poulain (from Nokia): Webkit trunk only support the current version of Qt, and the one in development. So, currently we only support Qt 4.6, and the branch of Qt 4.7. There has been a period of transition after the release of 4.6, but this is over and 4.5 is not supported anymore for WebKit trunk. Could you please re-consider upgrading to qt4.6 ? I've seing many build-qt-bots failures related to the bot only supporting qt 4.5. Thank you so much. On Tue, Feb 16, 2010 at 10:13 PM, Adam Barth aba...@webkit.org wrote: It looks like the Qt build now requires Qt 4.6. Currently, the qt-ews is using Ubuntu Karmic (which has Qt 4.5). I'll upgrade the machine to Lucid, but, in the meantime, the qt-ews will be down. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Make commit bot to update patch title after landing?
Hi, I think the commit bot should change the patch title after landing it, mentioning the changeset. For example: - patch title before landing: proposed fix - same patch landed by the commit bot, but w/ title referring to the changeset: commited in changeset X: proposed fix. It could make reading bugs easier, once the commit bot clears all review flags (r+ and cq+ for example) after landing. @Eric, Adam, what do you think ? -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] rfc: Spatial Navigation feature for WebCore
Hi, The Spatial Navigation feature consists in the ability to navigate between focusable elements, such as hyperlinks and form controls, within a structured document or user interface according to the spatial location. [1]. It is currently implemented in some desktop browsers including newer Opera versions and Firefox, as well as vastly used on non-touch mobile browsers. [1] http://en.wikipedia.org/wiki/Spatial_navigation During the last week I've moved forward in this feature implementation within WebCore in bug 18662 [2], and now I think it has reached a point where comments and official reviews are required to get this in at some point. [2] https://bugs.webkit.org/show_bug.cgi?id=18662 About the newer version of the patch (at the time of writing [3]): * It implements a super-precedence based algorithm, falling back into the classic Euclidean Distance approach. Details in the patch. * Is turned off by default, but has has toggle on/off API for QtWebKit also pending review in bug 33714. * It includes layout tests for some edge-cases, and a patch hook Qt DRT in bug 33715. [3] https://bugs.webkit.org/attachment.cgi?id=46576 This patch also skips the above added tests in Win, Mac and Gtk DRT, but followup bugs will track adding support for them. Also, known issues like form integration and other listed in the bug are also to be covered in follow up bugs (some already under implementation). Thanks in advance. -- --Antonio ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] First Early Warning System (EWS) bot online
Hi. Q) Why doesn't the EWS post a success message? I like positive re-enforcement. A) I'm worried about spamming bugs with too many happy status messages. If we have N ports with EWS bots, we don't want to have N happy status messages. Eric and I have some ideas for a more passive success indicator. Once things are running smoothly, we can share some mocks with the list. I particularly like not spamming bugzilla in case of successful builds, and IMO the code-style bot should not post a message either in case of no errors. Great work on both build and style bots despiting my previous personal opinion. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Bugzilla flood by the commitbot ?(was: First Early Warning System (EWS) bot online)
Speaking of which, I also love the commit bot thing, but IMO when it commits a R+ and CQ+ patch, it submits too much (three) entries to the bugzilla: 1) one cc'ing esei...@chromium.org 2) one doing the commit itself 3) and finally marking the bug as FIXED. @Eric, Adam, is there a way to reduce that to two or even on submit to bugzilla ? e.g. merge _1_ and _3_ maybe ... On Tue, Jan 5, 2010 at 3:51 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 5, 2010, at 10:21 AM, Adam Barth wrote: On Tue, Jan 5, 2010 at 9:42 AM, tonikitoo (Antonio Gomes) toniki...@gmail.com wrote: Q) Why doesn't the EWS post a success message? I like positive re-enforcement. A) I'm worried about spamming bugs with too many happy status messages. If we have N ports with EWS bots, we don't want to have N happy status messages. Eric and I have some ideas for a more passive success indicator. Once things are running smoothly, we can share some mocks with the list. I particularly like not spamming bugzilla in case of successful builds, and IMO the code-style bot should not post a message either in case of no errors. I agree, but this behavior was specifically required by Maciej when we brought the bot online. s/required/requested/ I'd be happy to change it if that's what folks would prefer. One possibility is to incorporate the status bubbles directly into bugs.webkit.org directly instead of requiring the extension. I find the status bubbles easier to use than hunting for the success / failure message when reviewing a patch. I think something like the status bubbles would be more useful than the success comment, though I also find the success comment more useful than nothing. - Maciej -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Error handling support in DRT.
It was agreed on IRC that having DRTs able to handle error pages in not a bad thing, but good since it brings DRT closer to a real browsers behavior. Hence, I moved on here and implemented it for QT's DRT (see https://bugs.webkit.org/show_bug.cgi?id=31509#c0). Currently the single test depending on it is fast/history/back-forward-reset-after-error-handling.html (see https://bugs.webkit.org/show_bug.cgi?id=30573), which is in gtk, win and mac 'Skipped' for now. Also, I've filed follow up bugs for each of these DRT to track down the implementation of such feature for their DRTs: * MAC - https://bugs.webkit.org/show_bug.cgi?id=31555 * GTK - https://bugs.webkit.org/show_bug.cgi?id=31556 * WIN - https://bugs.webkit.org/show_bug.cgi?id=31557 Regards -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Error handling support in DRT.
Thanks for replying, Darin. Comments below ...
WebKit itself does not have error pages. This is a feature of specific
browsers: Recent versions of Safari do this, although earlier versions used
sheets and alerts instead.
I agree that supporting error pages is a browser-specific feature.
The point is that WebCore::FrameLoader gives FrameLoaderClient the
right hook to load error pages and even has special treatment for when
it happens: If you look close at snippet FrameLoader code in
http://pastebin.com/f176c3bf5, it is obvious that
m_delegateIsHandlingProvisionalLoadError , for example, is
preventing that method body to get executed if an error page is
being handled:
(...)
m_delegateIsHandlingProvisionalLoadError = true;
m_client-dispatchDidFailProvisionalLoad(error);
m_delegateIsHandlingProvisionalLoadError = false;
(...)
In the sequence:
(...)
// Finish resetting the load state, but only if another load hasn't
// been started by the delegate callback.
if (pdl == m_provisionalDocumentLoadeer)
clearProvisionalLoad();
else if (m_provisionalDocumentLoader) { THIS IS THE PROBLEM
KURL unreachableURL = m_provisionalDocumentLoader-unreachableURL();
if (!unreachableURL.isEmpty() unreachableURL == pdl-request().url())
shouldReset = false;
}
Just checking for m_provisionalDocumentLoader (the 'else' block) is
not enough to ensure if a load error has been loaded or not. in my
opnion, it should be activeDocumentLoader(). As is, shouldReset
keeps as true and back/forward status gets broken.
I have patched it and even made a layout test and qt unittests [1],
but w/o DRT to support error pages my test is invalid.
[1] https://bug-30573-attachments.webkit.org/attachment.cgi?id=42829
I think it’s reasonable to have a way in DumpRenderTree to indicate somehow
in its output if a page load fails and what error code is involved. But I
would not recommend using error pages as the way to do this. And we’d have
to be careful to make this something easy to use cross-platform. Specific
error codes are also likely to be platform-specific.
The error page I made for QT is simple data:html/test,body/, just
in order to let something to get rendered. So I am not caring much
about the type of error here for now ...
There may be some way to accomplish this in some cases using onerror and
frames.
As far as I could see onError are to catch runtime JS execution
exception, which from the problem description above it can not be
enough (?).
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Test coverage for FrameLoader
Hi, As I replied in the bug, i totally agree about patch needing a test, and more generically that Test Coverage is something to be improved (not to get worse). Talking in my own defense, (again) i knew patch was not yet ready to get in (no tests) but since I do not have a MAC box handy and then can not run current MAC layout tests, I actually requested for comments from people i know touched the code lately. I was even hoping that maybe to some one w/ a Mac to run the test batch w/ and w/o the patch to see if it breaks what is already there, however i did not explicitly expressed my desire in the bug and ... So Adam, please do not take me wrong by requesting review for this not-yet-ready-to-be-reviewed patch. I believe almost every body already did what i did :-) /me would love try servers to be available. On Tue, Oct 20, 2009 at 4:26 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 20, 2009, at 12:50 PM, Adam Barth wrote: The usual WebKit policy is not to accept functional changes without regression tests. I'd like to ask that this policy be enforced strictly for FrameLoader. For example, I don't think we should be taking changes like this without tests: https://bugs.webkit.org/show_bug.cgi?id=30573 This policy is going to block fixing some FrameLoader bugs until we creating a better loading test harness, but I think the long-term benefits will out-weigh the short term costs. To clarify, we haven't been 100% strict about this in the past for areas of the code where we don't have the proper test infrastructure. That being said, it's probably time to build more infrastructure for testing page loading properly. Also, back/forward specifically can already be tested in DumpRenderTree, albeit somewhat awkwardly (assuming the symptom of this bug will manifest just by going back and forward). - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] FrameLoader cleanup
Adam, something else that imho must be considered ( while refactoring
the state machine ) is adding a load type that specifically does not
touch session and global history, and avoid abusing some of the
existent load types like below:
abuse
// FIXME: This seems like a dangerous overloading of the meaning
of FrameLoadTypeReload ...
// shouldn't a more explicit type of reload be defined, that means roughly
// load without affecting history ?
if (shouldReloadToHandleUnreachableURL(newDocumentLoader)) {
ASSERT(type == FrameLoadTypeStandard);
type = FrameLoadTypeReload;
}
/abuse
great effort so far , btw
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding a load type that specifically does not touch session and global history
Hi Adam,
although the lockHistory naming suggests it to be related to what I
pointed ou, they are currently not ..
ps: i totally also agree they could work together here.
From what i could understand (and for the test cases i faced for this
missing load type in the past), in current FrameLoader state there are
some other more related methods to this load w/o touching history
thing, including ::shouldReloadToHandleUnreachableURL and
::shouldTreatURLAsSameAsCurrent , among others.
Generally speaking, If SubstitutionData is valid (see
FrameLoader::load overloaded method), but it holds invalid failingURL,
session and global history are not changed, but it is *only* handled
in HistoryController::updateForStandardLoad().
My initial suggestion would to re-think the above method, considering
this possibly new load type.
On Tue, Oct 13, 2009 at 11:27 AM, Adam Barth aba...@webkit.org wrote:
There's a notion of lockHistory in FrameLoader. Is that related to
what you mean? I haven't studied load type yet.
Adam
On Tue, Oct 13, 2009 at 8:22 AM, tonikitoo (Antonio Gomes)
toniki...@gmail.com wrote:
Adam, something else that imho must be considered ( while refactoring
the state machine ) is adding a load type that specifically does not
touch session and global history, and avoid abusing some of the
existent load types like below:
abuse
// FIXME: This seems like a dangerous overloading of the meaning
of FrameLoadTypeReload ...
// shouldn't a more explicit type of reload be defined, that means roughly
// load without affecting history ?
if (shouldReloadToHandleUnreachableURL(newDocumentLoader)) {
ASSERT(type == FrameLoadTypeStandard);
type = FrameLoadTypeReload;
}
/abuse
great effort so far , btw
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] About IconDataba's threading behaviour and non-mac ports
I've just noticed a strange behaviour in WebCore's IconDatabase class.
In the Qt port code we provide a method for client applications to enable
and open WebCore's icon database for its use. It is done by calling the
following code:
(...)
void QWebSettings::setIconDatabasePath(const QString path) {
WebCore::iconDatabase()-delayDatabaseCleanup();
if (!path.isEmpty()) {
WebCore::iconDatabase()-setEnabled(true);
QFileInfo info(path);
if (info.isDir() info.isWritable())
WebCore::iconDatabase()-open(path);
(...)
However, if one calls
Image* image = iconDatabase()-iconForPageURL(KURL(url).string(),
IntSize(16, 16));
it does not return a valid WebCore::Image pointer at the first time it
is called, but works afterwards.
I mean, any subsequent call to IconDatabase::iconForPageUrl after the
first call works fine
(once icon already has its data set).
I started investigating it and I found out that at the first call,
IconDatabase's
haven't read icon data from the disk yet (lazy load) and
IconDatabase::iconForPageUrl
method just sets the given Url as pending icon reading (m_iconsPendingReading)
and returns '0'. A thread starts background and reads the Icon data
from the disk/db.
(see backtrace of a IconRegards::setImageData call here
http://pastebin.com/f1b25107f)
I found the (big) commit when this behavior was introduced, back in 2007:
git 6e7e49eaec8a45ba92a4d0fdce893e3dcd8832b5 , svn r25439 . In the commit
Brady mentions the following:
This will have a noticeable effect on current Safari 2 and Safari 3
beta browsers,
including icons not appearing in book or the location field the first
time they're asked for,
as current released Safari's don't properly listen for these asy. The
second time such a menu or
view is brought up, the icon should be there.
Since it is a known/intentional behavior, I'd like to know how do
other ports can work it around ?
What to listen to make it work always ?
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Towards a commit-queue
I went through the queue tonight and manually marked the bugs as commit-ready by adding [commit+] to their titles. This worked well, except that it made the bug titles ugly. I think a better solution is to have flag analogous to r+ which is commit+. Adam, as I suggedted previously, bugzilla supports KEYWORDs, so that would be a matter of adding a special support for bugs where patches are ready to go in. 'checkin-needed' keyword would work , i believe. What do you think ? these are the currently supported keywords: https://bugs.webkit.org/describekeywords.cgi -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] freeing static variables
Zoltan, I think it would be a great add from a embedder-dev point of view. Particularly, such leaks have been faced here in a soon past, when we were loading a webkit browser as a plugin, and not as an application by itself. So, we the webkit plugin was unloaded, it used to left behind lots of leaks affecting the (main) loader application, and as we you might imagine many of this leaks were from global vars (including in dependency libs , e.g. fontconfig =/) On Wed, Jul 29, 2009 at 4:05 AM, Zoltan Herczegzherc...@inf.u-szeged.hu wrote: Hi all, Valgrind reports a lot of memory leaks when QtLauncher quits, because many static local variables are not freed. I did a little research and realized there is no consistent way to define static variables in webkit: WebCore/css/CSSSelector.cpp: CSSSelector::extractPseudoType() using a DEFINE_STATIC_LOCAL() macro WebCore/bindings/js/JSDOMWindowBase.cpp: JSDOMWindowBase::commonJSGlobalData() static JSGlobalData* globalData; WebCore/platform/qt/CursorQt.cpp: Cursors* Cursors::s_self = 0; (no static keyword) I belive it would be a good thing to define a template for static variables, which can (optionally) free static variables (enabled in debug mode, but sometimes it would be good to enable it in release mode as well) And I am wondering whether it would be worth to free (some) static variables if they are used in a given time period. This may help to reduce the memory consumption in the long run. This would be an optional feature, an extra flag (or timeout value) for the template, which can be enabled or disabled at compile time. If disabled, the value of this flag is not used at all. Regards Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] default font size in WebKit
If the font size is not specified in the HTML page, what is the default one used by webkit? Haithem, (although i might be wrong) I believe different ports have different default font sizes. Qt is 14, for example. iirc, windows is 18 ... -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Possibly bogus FrameLoader::originalRequest data
Bug filed: https://bugs.webkit.org/show_bug.cgi?id=27444 On Fri, Jul 17, 2009 at 4:04 PM, tonikitoo (Antonio Gomes)toniki...@gmail.com wrote: Answering myself, that could explain things : @FrameLoader.h (...) // Document loaders for the three phases of frame loading. Note that while // a new request is being loaded, the old document loader may still be referenced. // E.g. while a new request is in the policy state, the old document loader may // be consulted in particular as it makes sense to imply certain settings on the new loader. RefPtrDocumentLoader m_documentLoader; RefPtrDocumentLoader m_provisionalDocumentLoader; RefPtrDocumentLoader m_policyDocumentLoader; (...) please , could someone confirm ? On Fri, Jul 17, 2009 at 12:28 PM, tonikitoo (Antonio Gomes)toniki...@gmail.com wrote: Hi. So I ran into this while developing a feature to qt webkit, but it is possibly not a port specific issue, but webcore. 1) If i load an existent local page (through FrameLoader::load) that redirects (e.g. file:///test1.html redirects to file:///test2.html) , i get FrameLoader::originalRequest.url() to point to test1.html FrameLoader::request.url() to point to test2.html which seems to be the corrent behavior. 2) After that if i load another local but unexistent file (e.g. file:///unexistent.html) i get: FrameLoader::originalRequest.url() *still* points to test1.html (previous loaded URL) FrameLoader::request.url() points to file:///unexistent.html whereas originalRequest pointing to a previous loaded url seems clearly no right. So, please correct if I am wrong, but there should be a method resetind these data between this two load calls ? also if I skip 1) and go to 2) straigh I get: FrameLoader::originalRequest.url() as an empty URL FrameLoader::request.url() to point to file:///unexistent.html Is that expected ? What data should originalRequest hold in these cases ? thanks -- --Antonio Gomes -- --Antonio Gomes -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] onfocus signal
you could have a look at WebKit/your working
port/WebCoreSupport/EditorClientXXX.cpp :
void EditorClientXXX::setInputMethodState(bool active)
{
... code could come here ...
}
On Sat, Jul 18, 2009 at 7:10 AM, Nikolas
Zimmermannzimmerm...@physik.rwth-aachen.de wrote:
Am 18.07.2009 um 13:02 schrieb Dan Antebi:
Lo,
Can anyone direct me to an onfocus signal?
Basically, I would like to pop up a virtual keyboard when in input field
(very much like iphone) for a touch screen kiosk deployment (linux, GTK).
Many thanks
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Possibly bogus FrameLoader::originalRequest data
Hi. So I ran into this while developing a feature to qt webkit, but it is possibly not a port specific issue, but webcore. 1) If i load an existent local page (through FrameLoader::load) that redirects (e.g. file:///test1.html redirects to file:///test2.html) , i get FrameLoader::originalRequest.url() to point to test1.html FrameLoader::request.url() to point to test2.html which seems to be the corrent behavior. 2) After that if i load another local but unexistent file (e.g. file:///unexistent.html) i get: FrameLoader::originalRequest.url() *still* points to test1.html (previous loaded URL) FrameLoader::request.url() points to file:///unexistent.html whereas originalRequest pointing to a previous loaded url seems clearly no right. So, please correct if I am wrong, but there should be a method resetind these data between this two load calls ? also if I skip 1) and go to 2) straigh I get: FrameLoader::originalRequest.url() as an empty URL FrameLoader::request.url() to point to file:///unexistent.html Is that expected ? What data should originalRequest hold in these cases ? thanks -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] possible wrong implementation visible_units....@logicalstartofline
Hi, honorEditableBoundaryAtOrAfter does check whether the visPos is null or not, and if it's null, then it returns the original visible position, so it's harmless (i.e. does not crash or has a side-effect). But I'm not sure what the caller of logicalStartOfLine is expecting; maybe we're supposed to do something in the case visible position was null. But assuming that the original is correct, we don't need that if statement at all. Exactly , I am trying to understand from the equivalent logicalEndOfLine implementation what a null-check there is supposed to prevent here ... (so at first glance i am supposing it was *not* a typo in the code, but as you said it could had been) Did you file a bug for it? Ryosuke just did: https://bugs.webkit.org/show_bug.cgi?id=27154 -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to prepare-ChangeLog
I grew up listing and seeing people not writing their emails *as it* and publishing on the internet so would replacing m...@apple.com by mjs at apple dot com be a good practice ? it reduces the spam count in your inbox for sure. On Thu, Jul 9, 2009 at 2:11 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 9, 2009, at 8:52 AM, Darin Adler wrote: On Jul 9, 2009, at 1:47 AM, Maciej Stachowiak wrote: (the /b/ URL is a redirect): I'm like most everything suggested in this thread. But I'm a little sad that these new shorter URLs are redirects. I really like to copy URLs out of the address field, so I’d want the legacy show_bug.cgi one to be the redirect, and the terse one to be the real URL. But that seems impossible, possibly eternally so, if the /b/ one is at webkit.org and not on the actual bugs.webkit.org server. Mark and I discussed this and had two ideas: 1) Something draggable/copyable in the bugzilla page that gives you the short URL plus title in ChangeLog format. 2) A keyboard shortcut (perhaps Cmd+Shift+C?) to put the short URL plus title on the pasteboard for ease of pasting I also don’t love the Authors line as proposed. I normally prefer something a bit less structured and formal for the case where there is some sort of collaboration. See existing log entries with things like Based on idea by etc. That's what I usually do too. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] possible wrong implementation visible_units....@logicalstartofline
Hi,
trying to understand this part of the webcore code, I faced a possibly
wrong impl:
(...)
VisiblePosition logicalStartOfLine(const VisiblePosition c)
{
VisiblePosition visPos = logicalStartPositionForLine(c);
if (visPos.isNull())
return c.honorEditableBoundaryAtOrAfter(visPos);
return c.honorEditableBoundaryAtOrAfter(visPos);
}
(...)
note that c.honorEditableBoundaryAtOrAfter(visPos); will be
executed regardless visPos being null or not. thoughts ?
commit : r43032
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] [Feature request] Bugzilla: default unassignee emails to per component.
Guys, I would like your opinion about the following feature request add in WebKit's bugzilla. Now, for every bug filed there is a default assignee ( webkit-unassig...@lists.webkit.org). In order to make possible for developers to follow bug activities of a specific component. My proposal is the existence of default assignees per component. e .g.: * qtwebkit-unassig...@lists.webkit.org * tests_tootls-unassig...@lists.webkit.org * (,,,) and so for other components. That way, people could use the user watching feature to track specific component activities via email (see bugzilla home page - preferences - email preferences - user watching option at the bottom) . Thoughts ? -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Feature request] Bugzilla: default unassignee emails to per component.
Hi Willian and Darin, I am pretty familiarized to bugzilla ecosystem and use and I also agree w/ both of you that my proposal would not be an ideal solution... I am really want to fire a discussion about improvements on it. Is getting emails the most practical way here for such ? If so, how do we easily do this ? br On Mon, Jul 6, 2009 at 2:05 PM, William Siegrist wsiegr...@apple.comwrote: On Jul 6, 2009, at 12:59 PM, tonikitoo (Antonio Gomes) wrote: Guys, I would like your opinion about the following feature request add in WebKit's bugzilla. Now, for every bug filed there is a default assignee ( webkit-unassig...@lists.webkit.org). In order to make possible for developers to follow bug activities of a specific component. My proposal is the existence of default assignees per component. e .g.: * qtwebkit-unassig...@lists.webkit.org * tests_tootls-unassig...@lists.webkit.org * (,,,) and so for other components. That way, people could use the user watching feature to track specific component activities via email (see bugzilla home page - preferences - email preferences - user watching option at the bottom) . Thoughts ? You could also perform an advanced search with whatever component criteria you wanted, then use the RSS feed from the results to watch for changes. -Bill -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] what's important in layouttests?
David, as far as I could understand your situation, you are not implementing a new Port of WebKit, so no support to a new toolkit or something. If that is the case, the existing platform you are using probably has layout tests already implemented. They are useful for regression tests mainly, among other stuff... 2009/6/29 David Jones ds...@163.com: hi,Dan, Oliver. If I want to take it into my project, what should I do? I do not understand this question. I want to write a simple browser with webkit. By posting this questin, I am wondering if I should also take the layouttest together with my browser project. 200万种商品,最低价格,疯狂诱惑你 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build Webkit_gtk I get errors in WebCore/platform/network/soup/ResourceHandleSoup.cpp?
you have probably an old version on libsoup-dev. ago...@tonix:~$ grep -nHR soup_message_headers_get_content_type /usr/include/ /usr/include/libsoup-2.4/libsoup/soup-message-headers.h:114:const char *soup_message_headers_get_content_type (SoupMessageHeaders *hdrs, ago...@tonix:~$ dpkg -l | grep soup ii libsoup-gnome2.4-1 2.26.0-0ubuntu3 an HTTP library implementation in C -- Share ii libsoup-gnome2.4-dev2.26.0-0ubuntu3 an HTTP library implementation in C -- Devel ii libsoup2.4-12.26.0-0ubuntu3 an HTTP library implementation in C -- Share ii libsoup2.4-dev 2.26.0-0ubuntu3 an HTTP library implementation in C -- Devel On Sun, Jun 28, 2009 at 11:01 PM, deuxliquiddeuxliq...@yahoo.com wrote: Hi everybody, after I run ./autogen.sh, I run make but I get some errors like below: WebCore/platform/network/soup/ResourceHandleSoup.cpp: In function ‘void WebCore::fillResponseFromMessage(SoupMessage*, WebCore::ResourceResponse*)’: WebCore/platform/network/soup/ResourceHandleSoup.cpp:155: error: ‘soup_message_headers_get_content_type’ was not declared in this scope WebCore/platform/network/soup/ResourceHandleSoup.cpp:179: error: ‘soup_header_g_string_append_param’ was not declared in this scope WebCore/platform/network/soup/ResourceHandleSoup.cpp: In function ‘void WebCore::gotHeadersCallback(SoupMessage*, void*)’: WebCore/platform/network/soup/ResourceHandleSoup.cpp:258: error: ‘soup_message_headers_get_content_type’ was not declared in this scope WebCore/platform/network/soup/ResourceHandleSoup.cpp: In function ‘void WebCore::gotChunkCallback(SoupMessage*, SoupBuffer*, void*)’: WebCore/platform/network/soup/ResourceHandleSoup.cpp:298: error: ‘soup_message_headers_set_content_type’ was not declared in this scope WebCore/platform/network/soup/ResourceHandleSoup.cpp: In function ‘void WebCore::ensureSessionIsInitialized(SoupSession*)’: WebCore/platform/network/soup/ResourceHandleSoup.cpp:458: error: ‘soup_session_get_feature’ was not declared in this scope make[1]: *** [WebCore/platform/network/soup/libWebCore_la-ResourceHandleSoup.lo] Error 1 Can you correct me? Thank you in advance! Hai Lướt web nhanh hơn Internet Explorer 8 tối ưu hóa cho Yahoo!, tự động khởi động 2 trang bạn thích mỗi lần mở trình duyệt. Tải IE8 tại đây! (Miễn phí) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] what's important in layouttests?
As addition resources, look at http://webkit.org/quality/testwriting.html and http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree to get into this deeper Br On Thu, Jun 25, 2009 at 11:04 PM, Oliver Huntoli...@apple.com wrote: Hi Dave, On Jun 25, 2009, at 7:54 PM, David Jones wrote: I am confused about webkit's layouttests. 1.What's the layouttess used for? Are they provided only for developers who want to create a browser with webkit to test if their browser behaves right? The (increasing inaccurately named) LayoutTests directory contains most of the regression tests used to try to ensure that no knew patch breaks any existing functionality. Every bug fix adds a new test so that the bug being fixed doesn't get reintroduced later. 2.The layouttests use Safari to run all the tests, right? No. The layout tests are run under the (also increasingly miss named) DumpRenderTree harness. Basically this is a per-platform application that embeds a webview with a set of additional APIs added to the DOM to improve our ability to test behaviour. 3.I noticed some tests need an app server, how do they start one? The http test directory requires a web server (i *think* apache), the run-webkit-tests script details at http://webkit.org/quality/testing.html will launch a new apache instance with all the correct parameters and settings required to get the correct behaviour. 4.Is layouttest only for Leopard? If I want to take it into my project, what should I do? The test suite is for webkit across all platforms. Some test do produce different output across platforms (particularly the pixel tests) but in general we try to ensure that the same test results are valid across all platforms and webkit ports. Hope this helps --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tab key Navigation
You can find default implementation in WebCore, yes:
void EventHandler::defaultKeyboardEventHandler(KeyboardEvent* event)
{
if (event-type() == eventNames().keydownEvent) {
m_frame-editor()-handleKeyboardEvent(event);
if (event-defaultHandled())
return;
if (event-keyIdentifier() == U+0009)
defaultTabEventHandler(event);
(...)
possibly , either chromium or safari are doing not-default stuff...
On Wed, Jun 17, 2009 at 11:18 PM, n179911n179...@gmail.com wrote:
Hi,
Is 'Tab key Navigation a browser functionality or Webkit functionally?
For example, I load google.com, I put my mouse on the search input box click
once. The search input box should have focus.
And then i press 'Tab', the focus should moved.
But what I find out is the way Safari moves focus is different from Chromium
(both uses Webkit but may be using different versions). So I would like to
know if the Tab key navigation a Webkit functionality or a Browser
functionality?
Thank you.,
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Review states
A possible solution (adopted by Mozilla) is the use of checkin-needed keyword. So: 1) In case of a patch with r+ and a commiter is assignee, all requested modifications can be needed before landing 2) when a patch has r+ and a non-commiter is assignee, it needs an updated patch (that can carry the previous r+ state - no further r=? request), and after addressing the comments, assignee can use the keywork CHECKIN-NEEDED. 3) when a patch has r+ plus changes request, assigneed to a non-comitter, w/out checkin-needed , it wont land until he updates. Seems not so hard as bugzilla supports keyworks already. On Wed, Jun 17, 2009 at 4:07 PM, Ojan Vafaio...@chromium.org wrote: On Wed, Jun 17, 2009 at 12:54 PM, Maciej Stachowiak m...@apple.com wrote: I forgot to mention - there should probably be a final Checked In state. I think that would help smooth out the workflow when people attach multiple patches to a single bug. It seems more clear than unflagging. Would be great if this also took a revision number (like how mark as duplicate takes a bug number) so it could add a link to the trac URL. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to cross compile Webkit for MIPS
deuxliquid, assuming that you have already a sandboxed toolchain set to cross compile webkit to your MIPS platform, your question can be considered quite vague ... please , inform in more details port you would like to build, compiler version, chroot you are using ... 2009/6/14 deuxliquid deuxliq...@yahoo.com: Hi all, I am working on Webkit for MIPS. How do I configure Webkit for MIPS? Anybody helps me? Thanks in advance! Hai Tốc độ nhanh, miễn quảng cáo, lưu trữ vô hạn - Yahoo! Mail mang đến cho bạn tất cả. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Another problem: how to dump flash content into image in Linux?
TianShijun,
QtWebKit (as well as Gtk and possibly others port) uses XEmbed to get
plugins (e.g. Flash) running. XEmbed is a X protocol to embed X window
onto others (containers). That said, when you try dumping flash by
the way you pasted below, you are not even touching the plugin
painting surface at all, but instead dumping the background image
QtWebKit draws under the XEmbed plugin window. Webkit has no control
of what flash is drawing. That is sorta default behavior on Linux ...
Windows we have ways to force flash to get painted onto WebKit drawing
surface, but it is unsupport by Flash on Linux. You are probably
looking for a *windowless* plugin implementation ...
2009/6/15 TianShijun tians...@hotmail.com:
Hi All,
I have tried to modify the PluginView::paint method in PluginViewQt.cpp to
dump the flash content. But the result is always a gray image. Does any one
know why? Or has anyone implemented the similar function before?
I have also tested the print/print preview function on many browsers
(Firefox, Konqueror, arora, Opera). None of them can print flash content. Is
there any way to implement it?
Thanks a lot.
PS: There may be a bug of PluginView::paint in PuginViewWin.cpp.While
dumping web page with flash content into image, the dumped flash content has
a doubled offset. It works well if we comment the SetWorldTransform lines
in PluginView::paintWindowedPluginIntoContext.
Here are the codes of my PluginView::paint in PluginViewQt.cpp. It always
outputs a gray image in Linux.
---
void PluginView::paint(GraphicsC ontext* context, const IntRect rect)
{
if (!m_isStarted) {
paintMissingPluginIcon(context, rect);
return;
}
//if (m_isWindowed || context-paintingDisabled())
//return;
//notImplemented();
if(context-paintingDisabled()) return;
PlatformGraphicsContext *painter = context-platformContext();
if(painter){
PlatformPluginWidget widget = platformPluginWidget();
if(widget){
//QPixmap pixmap = QPixmap::grabWidget(widget);
//QPixm ap pixmap = QPixmap::grabWindow(widget-winId());
//QPixmap pixmap =
QPixmap::grabWindow((WId)m_npWindow.window);
//widget-render(painter, QPoint(widget-x(),widget-y()),
QRegion(0,0,widget-width(),widget-height()),
//QWidget::DrawWindowBackground | QWidget::DrawChildren |
QWidget::IgnoreMask );
QPixmap pixmap(widget-size());
widget-render(pixmap);
pixmap.save(/tmp/test.ppm);
nb sp;painter-drawPixmap(QPoint(widget-x(),widget-y()),
pixmap);
}
}
}
立刻下载 MSN 保护盾，保障Messenger 安全稳定！ 现在就下载！
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to interrupt Webkit Dump Render Tree output
On Mon, Jun 1, 2009 at 1:31 PM, Simon Frasersimon.fra...@apple.com wrote:
There is a method on RenderObject to get the correct absolute coordinates of
the renderer, which correctly takes transforms, scrolling etc into account:
RenderObject::localToAbsolute(). This is not a trivial problem.
localToAbsolute() is only fragile because if you are querying for
the position of a renderobject inside an iframe, it is not relative to
mainFrame but to the currentFrame. I've done it like below:
static inline IntRect absoluteRenderRect(RenderObject* render)
{
ASSERT(render);
// FIXME: This function is flawed because it doesn't consider the
effects of CSS or SVG transforms.
IntRect rect(render-absoluteClippedOverflowRect());
// handle nested frames.
for (Frame* frame = render-document()-frame(); frame; frame =
frame-tree()-parent())
if(HTMLFrameOwnerElement* ownerElement = frame-ownerElement())
rect.move(ownerElement-renderer()-offsetLeft(),
ownerElement-renderer()-offsetTop());
return rect;
}
maybe there is a better way , but ...
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does anyone encounter this problem on NY times while using QWebKit?
I am seeing it too. Firefox 3.5preb4 renders its top bar all fine, fwiw. see http://farm4.static.flickr.com/3638/3560998719_d26d476d73.jpg?v=0 have you tried w/ other webkit ports ? it can be not qt-specific (?) br 2009/5/24 TianShijun tians...@hotmail.com: Hi All, I cannot open the www.nytimes.com correctly on a Qt port of WebKit. Can anyone help to verify or analysis the problem? While open nytimes in Qtlauncher(built with QT4.5, QT4.3.3) or QTDIR/examples/webkit/previewer(webkit integrated in QT 4.3.3), the topmost bar cannnot be rendered. Problem occurs in both Windows Vista and Kubuntu 9.04. Here is the picture: http://lh6.ggpht.com/_7B4pgaO4oRQ/ShlwpU8LuKI/ALw/WnRC34KnjDY/s912/nytimes.png Thanks! 立即试试微软地图新功能，msn互动浏览！ 立刻体验！ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Webkit JavaScript question
The last step depends on the architecture (supported or not) and C++ compiler directives. If JIT is enabled (see wtf/Platform.h), it always generates machine code. Otherwise an interpreter executes the byte code. A mixed environment (both jit and interpreter) is not yet supported. Are there plans for that ? Mozilla's TraceMonkey supports triggering JIT execution at runtine already, iirc. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Libcurl backend build error (was: build on ubuntu not working as expected)
Hi, That is something reproducible by every one who builds libcurl as network backend in a non-debug build, and really has to be fixed. Code looks like this: (...) WebCore/platform/network/curl/ResourceHandleManager.cpp #ifndef NDEBUG char* url = 0; curl_easy_getinfo(d-m_handle, CURLINFO_EFFECTIVE_URL, url); fprintf(stderr, Curl ERROR for url='%s', error: '%s'\n, url, curl_easy_strerror(msg-data.result)); #endif if (d-client()) d-client()-didFail(job, ResourceError(String(), msg-data.result, String(url), String(curl_easy_strerror(msg-data.result; (...) NOTE: url is declared inside the IFNDEF and used if the if statement outside that, which is obviously wrong. Problem: I build revision 41937 sometime back and wxBrowser and my own wxPython browser was working fine Today i updated to revision 43688. 1. First I got an error at line 329 platform/network/curl/ResourceHandleManager.cpp url not defined in this scope so i moved out char* url out of #ifndef NDEBUG -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to let webkit to be able to load local image file in html content?
It sounds like we can be misusing the base_url parameter. could you paste how you are calling the method (parameters and so) and a snippet of the local html file. On Wed, May 13, 2009 at 6:58 AM, Zhe Su james...@gmail.com wrote: Hi, When I call webkit_web_view_load_html_string() to load a html content into a webkitview, webkit always refuses to load local files (image) referred in the html content. Is it possible to work around this behavior and let webkit load local files? -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to detect the parameters in object tag?
Another way to go could depending on the port you are using. if it exposes DOM APIs (like qt does in trunk), for example, it is a matter of DOM: get element by its id, traverse its param child nodes, and get the name parameter value... On Tue, May 12, 2009 at 8:56 PM, naixuan guan guannaix...@gmail.com wrote: Hi, everyone Recently, I met a HTML page which has a object tag like this: OBJECT id=player style=LEFT: 0px; WIDTH:100%; TOP: 0px; HEIGHT:100% codebase= classid= param name=URL value=? PARAM NAME=ShowUI VALUE=1 PARAM NAME=volume VALUE=90 PARAM NAME=autoPlay VALUE=2 PARAM NAME=mute VALUE=0 PARAM NAME=DropEnable VALUE=0 PARAM NAME=EnableFullScreen VALUE=0 PARAM NAME=ShowVideo VALUE=1 param name=loop value=2/ /OBJECT script language=JavaScript document.player.URL = urlpath+file; /Script I have two questions 1.how to detect the parameters in object tag? 2.specially, how to detect the URL param which is changed by Javascript? Thank you! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
