Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
I am still seeing the problem(ofcourse, Sunnyvale, CA) ? any one, when this will be up? -Sravan. On Tue, Aug 7, 2012 at 9:20 AM, Osztrogonac Csaba o...@inf.u-szeged.huwrote: Hi, It seems bugs.webkit.org and trac.webkit.org is unavailable now. (at least from Hungary) Have you got any idea what happened? br, Ossy __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Fwd: hasStaticBlockPosition in RenderBlock::layoutPositionedObjects(bool relayoutChildren)
Hi,
Can some one please tell me who can clarify my doubts on Layout of
Positioned Objects, please?
-Sravan.
-- Forwarded message --
From: Sravan sra1sand...@gmail.com
Date: Fri, May 18, 2012 at 4:20 PM
Subject: hasStaticBlockPosition in
RenderBlock::layoutPositionedObjects(bool relayoutChildren)
To: webkit-h...@lists.webkit.org
Hello WebKittens,
In
RenderBlock::layoutPositionedObjects(bool relayoutChildren)
following code is actually supposed to setChildNeedsLayout to only those
positioned objects. When a non-positioned block element moves, and might
have positioned children that are implicitly positioned relative to
the non-positioned block.
// When a non-positioned block element moves, it may have
positioned children that are implicitly positioned relative to the
// non-positioned block. Rather than trying to detect all of these
movement cases, we just always lay out positioned
// objects that are positioned implicitly like this. Such objects
are rare, and so in typical DHTML menu usage (where everything is
// positioned explicitly) this should not incur a performance
penalty.
if (relayoutChildren ||
(r-style()-hasStaticBlockPosition(isHorizontalWritingMode())
r-parent() != this))
r-setChildNeedsLayout(true, MarkOnlyThis);
But, it looks like it is accidentally calling setChildNeedsLayout even on
those objects which has Absolute position mentioned exclusively through css.
And as
hasStaticBlockPosition(isHorizontalWritingMode())
checks for hasAutoTopAndBottom() in horizontalMode, when we provide
top/bottom attributes to any Absolute Positioned element through css,
then setChildNeedsLayout wont be called and hence we are seeing incorrect
layout.
I am able to fix this by editing hasAutoTopAndBottom() as follows
bool hasAutoTopAndBottom() const { return (top().isAuto() ||
top().isFixed()) (bottom().isAuto() || bottom().isFixed()); }
but the implementation does'nt really comply with the name, so either my
fix has to get a different function with a fix something similar as above,
or have a separate if block in RenderBlock::layoutPositionedObjects with an
entirely different implementation .
So, i do not want to submit a patch which will surely get a r-, and waste
reviewers time, also i would like to clarify on the bigger issue of
accidentally laying out positioned elements which the comment does'nt
really reflect.
*P.S: If by any chance i have successfully managed to confuse the reader,
please go through https://bugs.webkit.org/show_bug.cgi?id=80808 for the
use-case and relevant discussion.*
*
*
*I am not able to find a relevant person to discuss about this on IRC. so,
please CC yourself on that bug, and please comment there to continue the
thread.*
-Sravan.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] builds pending on cr-linux bot
Yes Thanks, its running now. -Sravan. On Mon, Apr 9, 2012 at 1:49 PM, Eric Seidel e...@webkit.org wrote: That builder just had a stuck build. I canceled the build, and things seem better. I believe I also fixed the bug which was hanging the commit-queue and chromium-linux EWS bots. Those should return to normal by morning (just in time for the rush!). -eric On Sun, Apr 8, 2012 at 10:56 PM, Eric Seidel e...@webkit.org wrote: Unclear what's going on with that builder. The CommitQueue also seems unhappy. Will poke around (I don't have access to the build bots, but I can look at the EWS/CQ.) On Sun, Apr 8, 2012 at 8:02 PM, Sravan sra1sand...@gmail.com wrote: Hi, I've submitted a patch almost 2 days ago, and i've seen that its still in queue. From http://build.webkit.org/builders/Chromium%20Linux%20Release i am seeing that builds are pending almost from 79hours. Can some one re-start/kick the bot to get the builds going. -Sravan. ___ 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
[webkit-dev] builds pending on cr-linux bot
Hi, I've submitted a patch almost 2 days ago, and i've seen that its still in queue. From http://build.webkit.org/builders/Chromium%20Linux%20Release i am seeing that builds are pending almost from 79hours. Can some one re-start/kick the bot to get the builds going. -Sravan. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing
Hi, If i get the context correct, then mime-type is automatically set to png files as Property changes on: abc.png ___ Added: svn:mime-type ## -0,0 +1 ## +image/png when we run ./Tools/Scripts/svn-create-patch if the svn version is 1.7+. But this is not being well received by ./Tools/Scripts/svn-apply while applying patch because it cant process above footer syntax in the patch. https://bugs.webkit.org/show_bug.cgi?id=80104 -Sravan. On Thu, Mar 8, 2012 at 5:07 AM, Simon Fraser simon.fra...@apple.com wrote: The best way to enforce it would be with a pre-commit hook: https://bugs.webkit.org/show_bug.cgi?id=80548 Simon On Mar 7, 2012, at 3:33 PM, Eric Seidel wrote: Unless this is enforced by a tool, it's very likely to be forgotten. https://bugs.webkit.org/show_bug.cgi?id=75824 https://bugs.webkit.org/show_bug.cgi?id=75825 On Wed, Mar 7, 2012 at 3:21 PM, Dan Bernstein m...@apple.com wrote: Please set the svn:mime-type property on binary files that you add to the tree, such as *-expected.png, before committing. Otherwise the resulting webkit-changes message will include those files as text, which is inconvenient. Thanks. ___ 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 ___ 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
[webkit-dev] Layout issue with fieldset legend element
Hi,
While working on webkit bug#:50287 (
https://bugs.webkit.org/show_bug.cgi?id=50287), i found another issue
related to legend element of fieldset form-property as described below.
On applying padding style information to fieldset legend element, the
bottom border gets clipped-off in Safari and Chrome. (Padding more than
8px).
There is no such issue on FF IE with any value or percentage of Padding.
Following is the simple test case to reproduce the issue on Safari and
Chrome.(Also attached as test.html)
html
head
style type=text/css
fieldset legend{
padding: 20px;
}
/style
/head
formfieldsetlegendHAPPY/legend/fieldset/form
/html
On analyzing further, I found that clipping of legend element is buggy in
WebKit, and i may have the fix for it.
I intend to submit this as a new bug, and submit the patch for it. Please
let me know if any one think otherwise.
-Sravan.
HAPPY
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
