Re: [webkit-dev] Mouse wheel event precision
On Tue, Jun 8, 2010 at 8:34 PM, Nathan Vander Wilt wrote:
> What Safari 5's WebKit does is turn one "line" into 4800 (!) units instead
> of 40. For Safari 5 the code above needs to read as follows to work the
> same. You can see it isn't really "more compatible" at all:
>
> var delta; // one scroll wheel "click" (corresponds to zoom
> level zoom level)
> if (isSafari5) {
>delta = e.wheelDelta / 120 / 120;
> } else if (e.wheelDelta) {
>delta = e.wheelDelta/120;
>if (window.opera && window.opera.version() < 9.2) {
>delta = -delta;
>}
> } else if (e.detail) {
>delta = -e.detail / 3;
> }
If you write a simple test page that demonstrates wheel events being handled
very differently by IE vs. Safari, please file a bug at bugs.webkit.org.
The goal of the current behavior is compatibility with IE.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse wheel event precision
On Jun 8, 2010, at 7:50 PM, Andy Estes wrote:
> Hi Nathan,
>
> It is true that Safari now emits mousewheel events in increments of 120 for
> compatibility reasons. However, there is no loss of granularity in the sense
> that events are generated on fractional wheel ticks and are accelerated on
> platforms that support it. The only difference is that you will see
> increments of 120 rather than increments of 1. It's been a few months since
> I've checked (and I can't look at the URL you attached on my phone), but I
> believe you'll see the same behavior in Chrome and IE.
I will not have access to IE for some time, but I think the old behaviour was
more compatible. I am not the original author of the OpenLayers code (just made
some un-integrated improvements, not shown below, to deal with WebKit's
wheelDelta acting like wheelDeltaX at times) but I think it demonstrates the
previous state of scroll wheel delta across browsers:
var delta; // one scroll wheel "click" (corresponds to zoom level
zoom level)
if (e.wheelDelta) {
delta = e.wheelDelta/120;
if (window.opera && window.opera.version() < 9.2) {
delta = -delta;
}
} else if (e.detail) {
delta = -e.detail / 3;
}
Webkit, IE and Opera seemed to be giving a wheelDelta in pixels or something
where one "line" was about 40 units, while Gecko gave a detail where one line
corresponds to 1 unit (assuming one old-school mouse wheel "click" scrolled ~3
lines).
What Safari 4 seemed to do was simply provide much greater precision, where
scrolling half a line simply yielded about 20 units instead of being ignored.
So the above code would yield integral deltas in browsers that only fired
events in 3-line increments, but nice fractional deltas in WebKit.
What Safari 5's WebKit does is turn one "line" into 4800 (!) units instead of
40. For Safari 5 the code above needs to read as follows to work the same. You
can see it isn't really "more compatible" at all:
var delta; // one scroll wheel "click" (corresponds to zoom level
zoom level)
if (isSafari5) {
delta = e.wheelDelta / 120 / 120;
} else if (e.wheelDelta) {
delta = e.wheelDelta/120;
if (window.opera && window.opera.version() < 9.2) {
delta = -delta;
}
} else if (e.detail) {
delta = -e.detail / 3;
}
It sounds like this was a well-intentioned change, but missed the fact that
that the values that are now being re-multiplied by 120 were *already* scaled
to the "1 'click' = 120 units" range.
hope this helps,
-natevw
> I would also point out that in DOM Level 3 Events, mousewheel events are
> considered deprecated and the unit of wheelDelta is left up to the
> implementor. IE set this increment to 120 some time ago, and we chose to
> match this behavior to be compatible with sites that expect it. As you can
> imagine, the opposite problem occurs on those sites (extremely slow
> scrolling). Unfortunately any decision we made here was bound to break some
> sites.
>
> -Andy
>
> Sent from my iPhone
>
> On Jun 8, 2010, at 19:09, Nathan Vander Wilt wrote:
>
>> In Safari 4, the following event handler would log nice smooth values when
>> scrolling:
>> // logs: -3, -9, -6, -48, ...
>> document.addEventListener("mousewheel", function(e) {
>> console.log(e.wheelDeltaY); });
>>
>> In Safari 5, the mousewheel events have lost all precision, and are now big
>> ugly integral multiples of 120:
>> // logs: -120, -240, -120, -480, ... (no correspondence with above values,
>> of course)
>> document.addEventListener("mousewheel", function(e) {
>> console.log(e.wheelDeltaY); });
>>
>> This is a serious loss of precision, and brings us back to the primitive
>> days when a mouse a had 1-axis clicky scroll wheel if it had one at all, and
>> Firefox was the top browser. Compare the smooth, precise scroll zooming of
>> http://calftrail.com/Share/multitouch/ in Safari 4 to the jerky,
>> way-too-fast zooming in Safari 5.
>>
>> Is this a regression introduced directly in recent WebKit builds, or is it
>> Safari-specific? If the former, was it really necessary and can it please be
>> rolled back?
>>
>> thanks,
>> -natevw
>> ___
>> 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
Re: [webkit-dev] Mouse wheel event precision
On Jun 8, 2010, at 19:50, Andy Estes wrote: > The only difference is that you will see increments of 120 rather than > increments of 1 Perhaps a better way to say this is that the old wheelDelta values are now simply being multiplied by 120. The precision hasn't changed, just the atomic unit of a "tick". -Andy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse wheel event precision
Hi Nathan,
It is true that Safari now emits mousewheel events in increments of 120 for
compatibility reasons. However, there is no loss of granularity in the sense
that events are generated on fractional wheel ticks and are accelerated on
platforms that support it. The only difference is that you will see increments
of 120 rather than increments of 1. It's been a few months since I've checked
(and I can't look at the URL you attached on my phone), but I believe you'll
see the same behavior in Chrome and IE.
I would also point out that in DOM Level 3 Events, mousewheel events are
considered deprecated and the unit of wheelDelta is left up to the implementor.
IE set this increment to 120 some time ago, and we chose to match this
behavior to be compatible with sites that expect it. As you can imagine, the
opposite problem occurs on those sites (extremely slow scrolling).
Unfortunately any decision we made here was bound to break some sites.
-Andy
Sent from my iPhone
On Jun 8, 2010, at 19:09, Nathan Vander Wilt wrote:
> In Safari 4, the following event handler would log nice smooth values when
> scrolling:
> // logs: -3, -9, -6, -48, ...
> document.addEventListener("mousewheel", function(e) {
> console.log(e.wheelDeltaY); });
>
> In Safari 5, the mousewheel events have lost all precision, and are now big
> ugly integral multiples of 120:
> // logs: -120, -240, -120, -480, ... (no correspondence with above values, of
> course)
> document.addEventListener("mousewheel", function(e) {
> console.log(e.wheelDeltaY); });
>
> This is a serious loss of precision, and brings us back to the primitive days
> when a mouse a had 1-axis clicky scroll wheel if it had one at all, and
> Firefox was the top browser. Compare the smooth, precise scroll zooming of
> http://calftrail.com/Share/multitouch/ in Safari 4 to the jerky, way-too-fast
> zooming in Safari 5.
>
> Is this a regression introduced directly in recent WebKit builds, or is it
> Safari-specific? If the former, was it really necessary and can it please be
> rolled back?
>
> thanks,
> -natevw
> ___
> 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] Mouse wheel event precision
In Safari 4, the following event handler would log nice smooth values when
scrolling:
// logs: -3, -9, -6, -48, ...
document.addEventListener("mousewheel", function(e) {
console.log(e.wheelDeltaY); });
In Safari 5, the mousewheel events have lost all precision, and are now big
ugly integral multiples of 120:
// logs: -120, -240, -120, -480, ... (no correspondence with above values, of
course)
document.addEventListener("mousewheel", function(e) {
console.log(e.wheelDeltaY); });
This is a serious loss of precision, and brings us back to the primitive days
when a mouse a had 1-axis clicky scroll wheel if it had one at all, and Firefox
was the top browser. Compare the smooth, precise scroll zooming of
http://calftrail.com/Share/multitouch/ in Safari 4 to the jerky, way-too-fast
zooming in Safari 5.
Is this a regression introduced directly in recent WebKit builds, or is it
Safari-specific? If the former, was it really necessary and can it please be
rolled back?
thanks,
-natevw
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCore Build Times
08.06.2010, в 15:21, Peter Kasting написал(а): I know someone once suggested that the build would be sped up if the #includes had longer paths (something like what happens in the Chromium tree) so that the toolchain didn't have to spend as much time scanning the (large) number of different directories on the #include path list. I believe Xcode keeps an in-memory map for file name to path mapping. This doesn't help other build systems, but the fact that build-webkit isn't blazing fast on Mac indicates that something else might be a culprit. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCore Build Times
Hi, For what it's worth I created "all-in-one" source files where they didn't already exist (css, dom, editing, history, etc.), and was able to drop my full rebuild time to a couple of minutes. -Ben On 6/8/2010 3:17 PM, Eric Seidel wrote: > Has anyone spent any time trying to reduce the number of includes in > WebCore? I know we have: > https://trac.webkit.org/browser/trunk/WebKitTools/Scripts/find-extra-includes > > But I feel like we still have way too many unnecessary includes. I > failed to find any tools for reducing build times or includes with my > brief Google searching. But perhaps others have looked into this > problem for WebKit or other projects? > > On my Intel Core 2 Duo MBP a full build takes over 1 hour. 5 years > ago, on my g4 laptop a full build took around 40m. :( We seem to be > slowly moving in the wrong direction. > > -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
Re: [webkit-dev] WebCore Build Times
On Tue, Jun 8, 2010 at 3:21 PM, Peter Kasting wrote: > > On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel wrote: >> >> Has anyone spent any time trying to reduce the number of includes in >> WebCore? I know we have: >> https://trac.webkit.org/browser/trunk/WebKitTools/Scripts/find-extra-includes >> >> But I feel like we still have way too many unnecessary includes. I >> failed to find any tools for reducing build times or includes with my >> brief Google searching. But perhaps others have looked into this >> problem for WebKit or other projects? > > I know someone once suggested that the build would be sped up if the > #includes had longer paths (something like what happens in the Chromium tree) > so that the toolchain didn't have to spend as much time scanning the (large) > number of different directories on the #include path list. However, I don't > know how true this is, and plus, converting all the files to use this method > would be a huge change (presumably done via a script). I imagine removing > unnecessary #includes, as you suggest above, would provide a much bigger > benefit. In a previous job, I spent a lot of time optimizing build times and reducing the number of include directories scanned made an enormous difference. However, that was C, not C++, and so the compilation and link steps were much faster than the preprocessing step (compared to C++, at least). I would still expect the file system scanning to be much slower than the actual preprocessing, so fixing include paths would probably still make a bigger difference than reducing unnecessary includes, but I'm not sure how much difference either contributes to the overall numbers. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCore Build Times
I think were I to try attacking this, I would write a script to generate a list of includes, and the number of cpp files which include them. Then I would work from the most-included end of that list, trying to reduce the number of files include each include. -eric On Tue, Jun 8, 2010 at 4:04 PM, David Kilzer wrote: > On Jun 8, 2010, at 3:17 PM, Eric Seidel wrote: > >> On my Intel Core 2 Duo MBP a full build takes over 1 hour. 5 years >> ago, on my g4 laptop a full build took around 40m. :( We seem to be >> slowly moving in the wrong direction. > > Was that before or after SVG was enabled in the engine? :) In general, I > think the amount of code in WebCore has increased since 2005, which probably > has more of an affect than unused headers. > > Having said that, I thought it would be useful to write a script that would > remove individual headers on a file-by-file basis and recompile WebKit to > find unused header candidates. I haven't had time to write such a script, > though. > > Dave > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCore Build Times
On Jun 8, 2010, at 3:17 PM, Eric Seidel wrote: > On my Intel Core 2 Duo MBP a full build takes over 1 hour. 5 years > ago, on my g4 laptop a full build took around 40m. :( We seem to be > slowly moving in the wrong direction. Was that before or after SVG was enabled in the engine? :) In general, I think the amount of code in WebCore has increased since 2005, which probably has more of an affect than unused headers. Having said that, I thought it would be useful to write a script that would remove individual headers on a file-by-file basis and recompile WebKit to find unused header candidates. I haven't had time to write such a script, though. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCore Build Times
would it be worth replacing #include with #include in all header files? On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel wrote: > Has anyone spent any time trying to reduce the number of includes in > WebCore? I know we have: > > https://trac.webkit.org/browser/trunk/WebKitTools/Scripts/find-extra-includes > > But I feel like we still have way too many unnecessary includes. I > failed to find any tools for reducing build times or includes with my > brief Google searching. But perhaps others have looked into this > problem for WebKit or other projects? > > On my Intel Core 2 Duo MBP a full build takes over 1 hour. 5 years > ago, on my g4 laptop a full build took around 40m. :( We seem to be > slowly moving in the wrong direction. > > -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
Re: [webkit-dev] WebCore Build Times
On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel wrote: > Has anyone spent any time trying to reduce the number of includes in > WebCore? I know we have: > > https://trac.webkit.org/browser/trunk/WebKitTools/Scripts/find-extra-includes > > But I feel like we still have way too many unnecessary includes. I > failed to find any tools for reducing build times or includes with my > brief Google searching. But perhaps others have looked into this > problem for WebKit or other projects? I know someone once suggested that the build would be sped up if the #includes had longer paths (something like what happens in the Chromium tree) so that the toolchain didn't have to spend as much time scanning the (large) number of different directories on the #include path list. However, I don't know how true this is, and plus, converting all the files to use this method would be a huge change (presumably done via a script). I imagine removing unnecessary #includes, as you suggest above, would provide a much bigger benefit. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebCore Build Times
Has anyone spent any time trying to reduce the number of includes in WebCore? I know we have: https://trac.webkit.org/browser/trunk/WebKitTools/Scripts/find-extra-includes But I feel like we still have way too many unnecessary includes. I failed to find any tools for reducing build times or includes with my brief Google searching. But perhaps others have looked into this problem for WebKit or other projects? On my Intel Core 2 Duo MBP a full build takes over 1 hour. 5 years ago, on my g4 laptop a full build took around 40m. :( We seem to be slowly moving in the wrong direction. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] problem with css :focus
isFocusedAndActive is asking if your frame is the focused frame and if the
window that contains your frame is also active. I would guess that you are not
setting the state of your frames/windows correctly. If your window is
considered inactive or if your frame is not considered focused, then :focus is
not going to be honored.
dave
(hy...@apple.com)
On Jun 8, 2010, at 3:33 AM, Alex Vazquez wrote:
> Hello list,
>
> We're running a customized build of WebKit (actually a DirectFB port) and we
> are experiencing problems with the css :focus pseudo-class. We use webkit as
> GUI renderer and, when changing the focused element through JavaScript (using
> the focus function), the style associated to the :focus pseudo-class is not
> applied. The attached page is our reduced testcase, it should show two links,
> the first of them focused but it shows two unfocused links:
>
>
>
>
>
>
>
> body {
> color: #f00;
> background-color:#ddd;
> font-size:26px;
> }
>
> div {
> float: left;
> padding: 50px;
> }
>
> a, span {
> float:left;
> display:block;
> clear:both;
> }
>
> a:focus {
> color:#f0f;
> }
>
>
>
>
>
> function init() {
> document.getElementById("uno").focus();
> }
>
>
>
>
>
>
>
>
> http://www.webkit.org/";>WebKit
> http://nightly.webkit.org";>Nightly Builds
>
>
>
>
>
>
>
> The version with this problem is based on r58260 revision while a previously
> one (with nearly the same adapted patches) based in r40084 worked fine. We
> build webkit for an embedded MIPS processor and for x86 too. Both versions
> show the undesired behaviour.
>
> Investigating through the WebKit code, we've found that applying the
> following patch fixes the problem:
>
> --- a/WebCore/css/CSSStyleSelector.cpp2010-06-04 13:35:19.0 +
> +++ b/WebCore/css/CSSStyleSelector.cpp2010-06-04 13:35:35.0 +
> @@ -2428,7 +2428,7 @@
> break;
> }
> case CSSSelector::PseudoFocus:
> -if (e && e->focused() &&
> e->document()->frame()->selection()->isFocusedAndActive())
> +if (e && e->focused())
> return true;
> break;
> case CSSSelector::PseudoHover: {
>
> That line was there since r40084 and it worked so we have some questions
> about the patch:
>
> * Does it have any problem that we have overlooked?
>
> * Can someone with knowledge on the css component explain why the active
> state of the selection is checked in that line? We also try to change that
> check by e->document()->frame()->selection()->isFocused() but it didn't fix
> it.
>
> Kind regards,
>
> --
> Alejandro Vazquez Fente
> ___
> 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
Re: [webkit-dev] Table hit testing
So I was just about ready to post a potential patch for keeping track of all cells that lie on a given grid slot. It seems that information is insufficient for correct rendering. Consider the attached test case: 1 R1C4 spans 4 rows, and should be drawn first. 2. R2C1 spans 4 columns and overlaps R1C4 (lies above it) 3. R4C1 spans 4 columsn and overlaps R1C4 (lies above it) Consider the case where the paint rect is the lower right grid slot. Knowing that R4C1 and R1C4 overlap, we draw R1C4 first and then R4C1 (in that order as they both lie inside the single slot dirty rect). Now we've drawn R1C4 ABOVE R2C1 This results in a rendering artifact. I'm currently working a solution that places cells in different layers and if a cell is dirty, we redraw it and all layers above it. How a layer is defined and formed and the data structures involved to do this efficiently will be discussed here shortly. Fady On Wed, Jun 2, 2010 at 4:40 PM, Fady Samuel wrote: > So I have completed all the following things locally: > > > * First fix the grid to record all the cells at a given position. This > fixes a repaint bug. > * Then change the hit-testing to work just like painting. This makes hit > testing more efficient and ensures hit testing and painting agree. > * Then optimize hit-testing to binary-search if there are no overflowing > cells. (And optimize painting similarly) > * Fix a table layout bug > * created a bunch of additional simple table layout tests > > I did all the pieces locally first to make sure I understand how all the > parts of table rendering fit together. However, I intend to get the pieces > of this work out in in smaller patches to simplify the review process for > reviewers. > > While I still have some more work to do testing, and splitting my work up > into the suggested pieces, please expect bug reports and proposed patches to > begin appearing shortly (within the next couple of days or so). > > Thanks, > > Fady Samuel > > > On Wed, Jun 2, 2010 at 7:34 AM, Fady Samuel wrote: > >> Ohh, I see, thanks Roland. >> >> Fady >> >> >> On Wed, Jun 2, 2010 at 3:25 AM, Roland Steiner >> wrote: >> >>> AFAICT you could have an arbitrary number up to the width or height of >>> the table, whichever is smaller, by combining row- and colspans - e.g. with >>> 3 ([v]aligns just to emphasize the overlapping): >>> >>> >>> R1C1R1C2>> valign=bottom>\\ >>> R2C1>> valign=bottom>// >>> >>> >>> >>> - Roland >>> >>> On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel wrote: >>> Hi David, Just so I'm certain, there's no way for more than two cells to overlap in a single grid slot, is there? Thanks, Fady Samuel On Thu, May 20, 2010 at 4:43 PM, David Hyatt wrote: > On May 20, 2010, at 3:38 PM, Fady Samuel wrote: > > > So what are the rules for stacking here? do the cells stack in the > order in which they appear in the HTML? > > > > Correct, although note that backgrounds paint behind foregrounds, and > hit testing works the same way, so it's not as simple as saying that cell > 7 > is always above cell 5. They're interleaved, so from bottom to top: > > Cell 5 background > Cell 7 background > Cell 5 foreground (the number "5" in this example) > Cell 7 foreground (the number "7" in this example) > > That's why if you hover over the actual number 5 in that example it > will light up, but if you're in the background area overlap, the number 7 > will light up. > > http://www.w3.org/TR/CSS21/zindex.html > > Therefore you do have to know about all the cells at the position, > since when you're in the "foreground" phase of hit testing, cell 7 will > say > "Nope, you're not inside my foreground", and so you then need to check > cell > 5, which will say "Yes, you are inside my foreground." > > The grid structure just isn't expressive enough. It needs to be > patched to track all cells in a given row/column instead of just the first > one. > > dave > (hy...@apple.com) > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> > Title: Paint bug R1C1 R1C2 R1C3 R1C4 R2C1 R3C1 R3C2 R3C3 R4C1 ___ webkit-dev mai
[webkit-dev] problem with css :focus
Hello list,
We're running a customized build of WebKit (actually a DirectFB port) and we
are experiencing problems with the css :focus pseudo-class. We use webkit as
GUI renderer and, when changing the focused element through JavaScript
(using the focus function), the style associated to the :focus pseudo-class
is not applied. The attached page is our reduced testcase, it should show
two links, the first of them focused but it shows two unfocused links:
body {
color: #f00;
background-color:#ddd;
font-size:26px;
}
div {
float: left;
padding: 50px;
}
a, span {
float:left;
display:block;
clear:both;
}
a:focus {
color:#f0f;
}
function init() {
document.getElementById("uno").focus();
}
http://www.webkit.org/";>WebKit
http://nightly.webkit.org";>Nightly Builds
The version with this problem is based on r58260 revision while a previously
one (with nearly the same adapted patches) based in r40084 worked fine. We
build webkit for an embedded MIPS processor and for x86 too. Both versions
show the undesired behaviour.
Investigating through the WebKit code, we've found that applying the
following patch fixes the problem:
--- a/WebCore/css/CSSStyleSelector.cpp2010-06-04 13:35:19.0
+
+++ b/WebCore/css/CSSStyleSelector.cpp2010-06-04 13:35:35.0
+
@@ -2428,7 +2428,7 @@
break;
}
case CSSSelector::PseudoFocus:
-if (e && e->focused() &&
e->document()->frame()->selection()->isFocusedAndActive())
+if (e && e->focused())
return true;
break;
case CSSSelector::PseudoHover: {
That line was there since r40084 and it worked so we have some questions
about the patch:
* Does it have any problem that we have overlooked?
* Can someone with knowledge on the css component explain why the active
state of the selection is checked in that line? We also try to change that
check by e->document()->frame()->selection()->isFocused() but it didn't fix
it.
Kind regards,
--
Alejandro Vazquez Fente
WebKit
Nightly Builds
--- a/WebCore/css/CSSStyleSelector.cpp 2010-06-04 13:35:19.0 +
+++ b/WebCore/css/CSSStyleSelector.cpp 2010-06-04 13:35:35.0 +
@@ -2428,7 +2428,7 @@
break;
}
case CSSSelector::PseudoFocus:
-if (e && e->focused() && e->document()->frame()->selection()->isFocusedAndActive())
+ if (e && e->focused())
return true;
break;
case CSSSelector::PseudoHover: {
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
