Konstantin Tokarev | 23 Jul 01:20 2016
Picon

Strange result in fast/backgrounds/mask-composite.html

Hello,

I'm getting attached result for fast/backgrounds/mask-composite.html, while in the tree expected
result looks like

https://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/fast/backgrounds/mask-composite-expected.png
https://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/fast/backgrounds/mask-composite-expected.png

Is it a known behavior change?

--

-- 
Regards,
Konstantin
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Konstantin Tokarev | 23 Jul 01:14 2016
Picon

"Fake" ref-tests

Hello,

I've stumbled upon two ref-tests:

fast/borders/border-painting-correctness-dashed.html
fast/borders/border-painting-correctness-dotted.html

Their references have a form of 

<style>
  body {
    margin: 0px;
  }
</style>
<body>
<img src="./resources/border-painting-correctness-dotted-expected.png" />
</body>

where img represents correct rendering of borders in mac port. As a result, these 2 tests are marked as
ImageOnlyFailure on gtk and ios-simulator, and probably don't pass on other ports as well.

What is the right way to deal with tests like these? I know that it's possible to create platform-specific
-expected.html and use different image in it, but I think it would be better to convert such tests to pixel tests.

--

-- 
Regards,
Konstantin
Danilo Cesar Lemes de Paula | 21 Jul 21:09 2016
Picon
Gravatar

JSObjectGetClass proposal

Hello there,

So, when working on a javascript binding engine we faced the following
problem:
How to create a JSObjectRef as the same type as another one.

With SpiderMonkey, we could use JS_GetClass to get the JSObject's class,
and then use that JSClass to build the new object.
There's no such API on JavaScriptCore.

I'd heard some suggestions to workaround the issue with Set/Get privates
or prototypes, but it definitely didn't get the expected result.

So, I know the JSObjectRef API has been stable for a while, but I would
like to propose the inclusion of the following API in the public list of
jsc APIs.

* JSClassRef JSObjectGetClass(JSObjectRef obj).

I can see this API being used for:
 * Knowing if two objects are from the same class (by using
JSValueIsObjectOfClass)
 * Creating dynamic constructors using another JSObjectRef as reference
for the class.

I did submit a bug and a patch for it:
https://bugs.webkit.org/show_bug.cgi?id=160032

Would be lovely if a JSC engineer could drop some thoughts or maybe a
review there...
(Continue reading)

Chris Aljoudi | 21 Jul 04:30 2016
Gravatar

High web process CPU usage

Hi all,

In the Safari shipped with the latest macOS Sierra beta, as well as Safari Tech Preview 9, there's an odd CPU usage issue with individual tab's web processes.

For example, if one navigates to huffingtonpost.com, Activity Monitor will show the tab web process continually using 5-10% of CPU, along with hundreds of idle wake-ups. Even more concerning, this continues to happen with the huffingtonpost.com web process even if one picks another tab in the window.

Here's a screenshot from Activity Monitor; one Safari window is open. It has two tabs: polymail.io, and about:blankabout:blank is the one currently in focus.


To investigate, I opened Web Inspector and recorded the JS/event timeline. I found that there were timers firing quite frequently.

Now, I know Safari/WebKit should be throttling timers of background tabs anyway, but I figured I'd `clearInterval` all the timers to see if that reduces the CPU usage. Nope (even though I verified no timers are firing any longer after clearing all the intervals — no activity on the timeline whatsoever; CPU usage and idle wake ups still way too high).

This doesn't happen with *every* page, but it happens with most that are reasonably complex (can't tell what the trigger is yet; perhaps the use of JavaScript timers?)

The previous Sierra beta's Safari and Tech Preview 8 both showed this problem. I don't know whether it goes further back.

Any ideas what's going on? Is this 'expected behavior' and I'm missing something obvious?

Thanks,
Chris
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Mark Davis | 20 Jul 14:28 2016
Picon
Picon

webkit not remembering or asking to remember passwords

Hi,
I have just installed webkit onto my g5 powermac.  It is working well,  
however does not send the usual message about remembering password  
details after logging into my accounts.

I have tried to work around this by going into preferences and the  
keychain utility, but still unsuccesful.

Any ideas?  cheers

Mark
Nikos Andronikos | 20 Jul 05:36 2016
Picon
Picon

Request for comments on some bindings generator patches

Hey all,

We’ve got some web animations related patches that are stalled waiting on feedback about options to update the bindings generator.

There’s currently three patches waiting to be reviewed, one Web Animations, two binding generator fixes.

Patch 1. Web Animations: https://bugs.webkit.org/show_bug.cgi?id=156096
Dean already gave this one r+. But it ended up causing a build issue when Web Animations was disabled, and was rolled back.
So it’s now waiting on the resolution of one of the other patches below.

Patch 2. Our preferred solution to the build issue that occurs with patch 1 is to add support for the Conditional extended attribute on the implements WebIDL statement. Then we can put a conditional on the implements statement that adds the Animatable interface to Element.
My colleague Rawinder did this in the following patch:
https://bugs.webkit.org/show_bug.cgi?id=158830
This patch stops the IDL preprocessor from looking for the IDL file at all, and all is well.

Patch 3: Another option to address the build issue is to move the Animatable.idl file out of the conditional in the CMake file list, so that the IDL preprocessor can find it and include it as a supplemental file. 
This _should_ be ok, because the internals of that file are protected by conditionals.
But there is another bug where the preprocessor is trying to include the file that defines the return type for Element.getAnimations(), which is sequence<WebAnimations>. The IDL file that defines the WebAnimations type is still hidden by a conditional in the CMake file list.
Rawinder submitted a patch to fix that as well: https://bugs.webkit.org/show_bug.cgi?id=158975
We’re ok with this solution, but don’t feel it’s as elegant as enabling conditionals on the implement statement.
This option copies Animatable.idl to DerivedSources, but at least it doesn’t generate any unused bindings code.

Another option is to move all the Web Animations IDL files out of the conditional in the CMake file list.
This seems really clunky and inefficient to me as it involves unnecessary work by the IDL preprocessor and generates unused bindings code. There are also problems with this solution, caused by the GObject bindings, that would need to be investigated and fix.
We could look at this, but because it’s not our preferred solution, are hesitant to get started. There’s a history of this sort of investigation being a deep rabbit hole that sucks up lots of time. I think we have enough to do with Web Animations by itself at this point.

It would be great to get some input on these bugs so we can continue with the web animations implementation.

Thanks!
Nikos The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Marco Barisione | 18 Jul 22:02 2016
Gravatar

./Tools/Scripts/run-safari doesn't work with Safari 10

Hello,

I recently installed Safari 10 on some machines running 10.11.6 DP. Unfortunately, I cannot get Safari 10
to work with WebKit compiled from SVN.

I tried with both SVN trunk (from today) and the revision tagged in SVN that corresponds to my currently
installed Safari (602.1.38.4).
I compiled Safari with the usual:

  $ ./Tools/Scripts/build-webkit

And then I tried to run Safari with:

  $ ./Tools/Scripts/run-safari

Safari 10 starts, but nothing loads probably because it cannot load its injected bundle. This is the output:

Starting SafariForWebKitDevelopment with DYLD_FRAMEWORK_PATH set to point to built WebKit in /Users/bari/src/webkit/WebKitBuild/Release.
2016-07-18 14:18:32.900 SafariForWebKitDevelopment[424:4918] [Keychain] SecItemCopyMatching
failed fetching extension list with error -34018
2016-07-18 14:18:32.923 SafariForWebKitDevelopment[424:4918] [Keychain] SecItemCopyMatching
failed fetching extension list with error -34018
2016-07-18 14:18:33.091 com.apple.WebKit.WebContent.Development[425:4983] Error loading
/System/Library/StagedFrameworks/Safari/Safari.framework/Safari: 
dlopen(/System/Library/StagedFrameworks/Safari/Safari.framework/Safari, 265): Symbol not
found: _OBJC_CLASS_$_WBSCompletionListRankingObserver
  Referenced from: /System/Library/StagedFrameworks/Safari/Safari.framework/Safari
  Expected in: /System/Library/PrivateFrameworks/SafariShared.framework/Versions/A/SafariShared
 in /System/Library/StagedFrameworks/Safari/Safari.framework/Safari
InjectedBundle::load failed - Could not load the executable from the bundle.

I’m a bit surprised that I couldn’t find anything about this problem in bugzilla, IRC or on this mailing list.
Am I doing something wrong or is this a problem with newer Safari? Is there any fix/workaround for this?

Thank you!

--

-- 
Marco Barisione

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Ryosuke Niwa | 18 Jul 02:57 2016
Gravatar

On Mac and iOS ports, you may need to trigger clean rebuilds after r203337

Objective-C bindings files may fail to re-generate after
https://trac.webkit.org/changeset/203337.  Simply trigger clean
rebuilds or delete files under DerivedSources/WebCore/ and it should
go away.

- R. Niwa
Konstantin Tokarev | 16 Jul 17:19 2016
Picon

"No red pixels below" automation

Hello,

There is a number of layout tests which are expected not to have red pixels in case of pass. Some of them are
purely pixel tests, which are not checked by bots (and not often by humans), others have render trees
dumps, but there many cases when render tree dump is right but end result is not because of painting bug, and
it's also easy to overlook one-pixel errors when doing rebaseline.

Was it ever considered to do automatic red pixel search in png result? Such tests could be run on bots and
increase regular coverage.

--

-- 
Regards,
Konstantin
Konstantin Tokarev | 14 Jul 17:03 2016
Picon

Is anyone here interested in improving rebaseline-server?

Hello,

Recently I was using rebaseline-server a lot to do large-scale local rebaseline, and I've collected a list
of glitches and inconveniences in its UI which make work less effecive than it could be, and would be nice to
get fixed.

Is anybody here using rebaseline-server as well, or everyone is using garden-o-matic?

--

-- 
Regards,
Konstantin
Konstantin Tokarev | 14 Jul 15:21 2016
Picon

Rounded dots in dotted border

Hello,

Document [1] says defines "dotted" style as "a series of round dots", however CG and Cairo implementations
draw dots as squares.

Are there any plans to implement rounded dots?

[1] https://www.w3.org/TR/css3-background/#border-style

-----

P.S. Some context in case anyone is interested:

I was rewriting drawLine() implementation in Qt port which was broken by r177686 (remember skewed border
in Bugzilla with Cairo? That thing), and found that implementations of drawLine() share the same logic
and differ in minor details only. However, out old code was drawing rounded dots, and I feel it would be more
appropriate to implement this logic in shared code, or drop it completely if other ports are not planning
to do this.

--

-- 
Regards,
Konstantin

Gmane