Re: [webkit-dev] svn-create-patch acting oddly lately

[Joseph Pecoraro]

It's kind of sad that we have so many ways of finding the SVN root.
The code in that link isn't right.  You need to look at the UUID to
get the right answer.  See scm.py.


Yes, I saw scm.py's solution literally yesterday while I was learning  
how to use bugzilla-tool because I switched to git.  In any case the  
newer revision uses a much better approach then the one in this  
changelog (Repository Root) and ultimately the best approach would be  
using the UUID like you suggested.

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

Re: [webkit-dev] svn-* scripts

[Joseph Pecoraro]

On Aug 21, 2009, at 8: 32PM, Darin Adler wrote:
I’m a little irritated that we’re changing our Subversion scripts,  
svn-create-patch, svn-apply, and svn-unapply into WebKit-specific  
scripts. Previously, they were scripts that were independent of the  
particular project that enhanced Subversion in a non-project- 
specific way. I used the WebKit version on many projects other than  
the WebKit project.


I think the names should change if we’re changing them to do WebKit- 
specific things.


I don't think the change I did before was WebKit specific.  And the  
changes (not committed) to svn-[un]apply only reflect the changes to  
svn-create-patch, but are again not WebKit specific.  These changes  
ensure that patches are created and applied from the root of any SVN  
Repository (which in fact is what git does by default and makes the  
most sense by removing any possible ambiguity or forcing someone to  
know which directory they should apply a patch).  There has been some  
loss of functionality [1], but that can be fixed.


[1] Create a patch without svn-create-patch which contains paths not  
from the repository's root and then attempting to use svn-apply or svn- 
unapply to deal with the patch.


These are the only changes I know of.  If there are any others its  
possible they may be WebKit specific.


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

Re: [webkit-dev] ENABLE(INSPECTOR) check in Console::lastWMLErrorMessage

[Joseph Pecoraro]

Hello Ryan,

 Looks like it should add ENABLE(INSPECTOR) check in 
 Console::lastWMLErrorMessage()
 (/trunk/WebCore/page/Console.cpp) Thanks.

Could you file a bug using this link?
http://webkit.org/new-inspector-bug

Please include any relevant error messages you're getting, such as
a compiler warning if there is a missing ENABLE(INSPECTOR) check.
It looks like you're compiling with WML enabled but without
INSPECTOR enabled. That would catch this problem! If thats it the
case someone will likely jump on this pretty quick. If you want you
can assign this to me and I can handle this tomorrow.

Better yet, if you'd like to try your hand and contributing a patch
that would be great! You can start here:
http://webkit.org/coding/contributing.html

Thanks!
- Joe

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

Re: [webkit-dev] ENABLE(INSPECTOR) check in Console::lastWMLErrorMessage

[Joseph Pecoraro]

On Apr 29, 2010, at 12:53 AM, Joseph Pecoraro wrote:
 Looks like it should add ENABLE(INSPECTOR) check in 
 Console::lastWMLErrorMessage()
 (/trunk/WebCore/page/Console.cpp) Thanks.

Ryan, I've created a bug and put up a few patches (2 desired behaviors):
https://bugs.webkit.org/show_bug.cgi?id=38366

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

Re: [webkit-dev] Meaning of PLATFORM(MAC) and platform/cocoa?

[Joseph Pecoraro]

 It seems like a good idea to share as much code as we can between ports
 rather than forking files.

Absolutely, that was the original reason behind platform/cocoa!


 To that end, would it be possible for someone to explain the exact meaning
 of PLATFORM(MAC) and the intended use of the platform/cocoa directory?

I added this to allow shared code between PLATFORM(MAC) and
PLATFORM(IPHONE). You can see some of the discussion and original
patches on this bug:
https://bugs.webkit.org/show_bug.cgi?id=35870

Checking the svn history on WebCore/platform/cocoa would give you some
history on it as well.


 If a certain file uses Cocoa and is shared between OS X ports (including 
 Chromium),
 where should the file go?

It could be that cocoa is a misleading name. We thought of darwin at the 
time.
But putting code in platform/cocoa would be fine if the code is shared. Do you
have a specific example in mind?

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

Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.

[Joseph Pecoraro]

On Aug 9, 2010, at 12:48 PM, Pavel Feldman wrote:
 See the screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium 
 nightly to the left +
 WebKit nightly to the right. WebKit nightly connects remotely to Chromium 
 over HTTP on the port
 9222 and does remote debugging including DOM inspection, breakpoints and such.

Great demo!


 [...] The blog post would draw attention to the Web Inspector and its 
 progress, share the remote
 debugging vision with the interested parties and would simply look cool. [...]
 

 What do you think, is it ready for a blog post?

The concern I had was that this isn't readily available in the browser for 
download
on webkit.org (WebKit nightly). In that way, I think for many it will feel a 
bit like a
teaser. However, WebKit is an open source project, so I'd expect to see all 
kinds of
WebKit related news and blog posts available there.

In the end I feel the more publicity the better. Especially when someone just
expressed an interest in seeing more interesting blog posts.

The last blog post on the Web Inspector was in April. Before that it was 
November.
That was a 5 month spread, and this would be a 4 month spread. Thats a pretty
consistent rate showing off awesome work.

- Joe

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

Re: [webkit-dev] Remote debugger

[Joseph Pecoraro]

Hello Sergiy,

I've got a bunch of links for different areas where work has been done.

Some information on the protocol and is outlined in the following links. I 
don't think they are up to date; I think things have improved and evolved since 
then. Pavel and Ilya may be able to comment more on the protocol since there 
has been quite a bit of work recently splitting it up into different domains to 
turn on/off debugging different domains or feature sets. But I think the 
protocol has been stable for a while. I think they even had some discussion 
with the Firebug team when they talked about a debugging protocol, but I can't 
seem to find where that discussion took place.
http://webkit.org/b/43732 Web Inspector: Remote debugging meta-bug
https://docs.google.com/document/edit?id=1d_N-OIb3UztuC-_g0piXsIIdp89HnMcDk-uSQ8uamW4hl=enauthkey=CIf48O4Jpli=1#

Here is a screencast, previously posted to this list, of it working in Chromium:
https://lists.webkit.org/pipermail/webkit-dev/2010-August/013797.html
http://screencast.com/t/YTI2OTY4YTEt

There has been some work on an internal WebKit solution based on Web Sockets:
http://webkit.org/b/43988 Web Inspector: Remote Web Inspector support for 
QtWebKit [Already Landed]
http://webkit.org/b/51364 Web Inspector: Remote Web Inspector - Cross 
Platform InspectorServer [Open - Issues to be Worked Out]

External to WebKit, Patrick Mueller has been working on weinre. Patrick is on 
this list and might comment more:
http://pmuellr.github.com/weinre/index.html (https://github.com/pmuellr/weinre)
http://muellerware.org/papers/weinre/manual.html

- Joe

On Feb 18, 2011, at 7:04 AM, Sergiy Temnikov wrote:

 
 Hello,
  
 I'm working on a remote JavaScript debugger for a server which uses webkit to 
 execute JavaScript code. The debugger is shaping up nicely and is already 
 very much functional. We chose Crossfire as the debugging protocol and 
 developed our own UI debugger client. However, being Crossfire-compatible, 
 should allow us in the (hopefully near) future to debug the server-side 
 JavaScript using Firefox with Firebug and Crossfire plug-ins. I was wondering 
 if there are any plans in the webkit community to create a native remote 
 JavaScript debugger as part of the webkit build. If there are such plans then 
 what would be the debugging protocol of choice? Webkit is already available 
 on mobile devices but because of the screen size limitations it is not always 
 reasonable to debug the Javascript directly on a device. Instead, it would be 
 nice to debug the device's  JavaScript from a regular PC over the network.
 If any of you are already working on a similar subject then please share your 
 thoughts and comments regarding your particular implementation, which 
 protocol you use and how you see remote debugging appearing in webkit.
  
 Regards,
  
 -Sergiy Temnikov
 
 
 
 3fa2fb.png  
 Sergiy Temnikov
 Architecte Logiciel
 Email :   sergiy.temni...@4d.com
 Web : www.4D.com
 4D SAS
 60, rue d'Alsace
 92110 Clichy - France
 Standard :+33 1 40 87 92 00
 
 
 
 
 
 
 
 
  
 
 
 ___
 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] ChangeLog format

[Joseph Pecoraro]

On Aug 22, 2013, at 12:46 AM, Carlos Garcia Campos carlo...@webkit.org wrote:

 El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
 On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
 
 I see, I thought ChangeLog parser was used everywhere. So, I guess the
 solution would be to find a format most people like and adapt all
 scripts to it. I personally think it's not worth it, though. The oneline
 git log format is ok with the old commit message format IMO. If the only
 problem is that the bug number is not in the first line we can probably
 add it without adding the URL in angle brackets, something like:
 
 Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
 https://bugs.webkit.org/show_bug.cgi?id=119872
 
 What benefit does duplicating the bug number in the first line provide? It’s 
 just yet another thing to have to add when writing the ChangeLog entry.
 
 The benefit is that you see the bug number when using git log oneline
 format, I'm guessing that seeing the bug number in the first line was
 the motivation of the new ChangeLog format.


I prefer the new format. However, the new format doesn't really gain us much, 
so it sounds like it is not worth the effort to change.

As for duplicating the bug number, I don't think that matters. `git log 
--oneline` shows a short SHA the title line which is everything in the commit 
message until the first empty line. So duplicating the bug number in the first 
line doesn't really help, since both of these lines already show up.

Old format:

shell git log --oneline `git svn find-rev r153963` -10
503293b Move additionalIdentifiers into DFGCommonData as only the optimising 
JITs use them https://bugs.webkit.org/show_bug.cgi?id=119705
2dbc921 Stop making unnecessary copy of CodeBlock Identifier Vector 
https://bugs.webkit.org/show_bug.cgi?id=119702
c0c68df [cairo] memory corruption with putImageData and accelerated canvas. 
https://bugs.webkit.org/show_bug.cgi?id=118621
0502819 Layout Test fast/overflow/scrollbar-click-retains-focus.html is failing 
on Apple Mac WK1 and GTK. https://bugs.webkit.org/show_bug.cgi?id=104104
c19a87b Use const AtomicStringImpl* in DocumentOrderedMap 
https://bugs.webkit.org/show_bug.cgi?id=119700
02c59d8 The LayoutMilestones didLayout callback should only fire for the main 
frame https://bugs.webkit.org/show_bug.cgi?id=119457
2cb3317 Remove didNewFirstVisuallyNonEmptyLayout from WebKit2 
https://bugs.webkit.org/show_bug.cgi?id=119658
6cb5165 Define DOM_KEY_LOCATION_* constants on KeyboardEvent 
https://bugs.webkit.org/show_bug.cgi?id=119341
597845d Remove glu's libtest rule from checker.py 
https://bugs.webkit.org/show_bug.cgi?id=119674
35852cd Multiple CSP tests complain about undefined strings in 
echo-object-data.pl and echo-script-src.pl 
https://bugs.webkit.org/show_bug.cgi?id=119692

New format:

shell git log --oneline `git svn find-rev r154274` -10
c3bd590 https://webkit.org/b/119882 Speed up moving cursor/selection up or 
down past non-rendered elements.
6c326ac https://webkit.org/b/119933 [Qt] Fix 
tst_QObjectBridge::connectAndDisconnect() fail
381c093 https://webkit.org/b/12 Chrome::client() should return a 
reference.
f183c4b https://webkit.org/b/120004 Rename StyleElement to 
InlineStyleSheetOwner and stop inheriting from it
0d74bc3 [Qt] QtWebKit (using the Arora browser) displays the border radii 
(radius) of a button very ugly https://bugs.webkit.org/show_bug.cgi?id=28113
e5a4a31 https://webkit.org/b/119998 [Qt] Build fix (broken since r154257).
d3ac166 https://webkit.org/b/120001 Clean up StyleElement
5c403bd https://webkit.org/b/119990 Add toSVGStopElement(Node* node) to 
clean-up a static_castSVGStopElement*
508cc36 https://webkit.org/b/119996 Introduce toSVGAnimateElement(), and use 
it
db5024b https://webkit.org/b/119997 Page::progress() should return a 
reference.

- Joe___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Windows a Release Build Broken

[Joseph Pecoraro]

Windows bots on build.webkit.org are now green.

Thanks for pointing me to the fixes in bugzilla comments.

- Joe


On Dec 25, 2013, at 9:23 PM, Brent Fulgham bfulg...@apple.com wrote:

 The changes in Bug 126091 breaks the Windows Release build.
 
 https://bugs.webkit.org/show_bug.cgi?id=126091
 
 -Brent
 
 Sent from my iPad
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

[Joseph Pecoraro]

I would also like to see a reduction in EWS spam.

It is not just the comment clutter, but also quite a bit of emails.

- Joe

On Jan 15, 2014, at 8:17 PM, Ryosuke Niwa rn...@webkit.org wrote:

 We could do that, or add some JS hack to Bugzilla so that it hides EWS 
 comments by default but makes them expandable.
 
 - R. Niwa
 
 
 On Wed, Jan 15, 2014 at 8:09 PM, Sam Weinig wei...@apple.com wrote:
 Could we compromise for now, and remove all the non-test failing EWS comments 
 (e.g. build failure, style failure)?
 
 - Sam
 
 On Jan 15, 2014, at 8:04 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 I find Mac EWS's listing the failing tests to be very useful especially 
 because it uploads the results to Bugzilla.
 
 I do agree that comments about build failures are much less useful.
 
 - R. Niwa
 
 
 On Wed, Jan 15, 2014 at 7:54 PM, Sam Weinig wei...@apple.com wrote:
 Hi Everyone,
 
 I am becoming increasingly annoyed by the comments made in bugs.webkit.org 
 bugs by our non-human helpers, the EWS bots.  I don’t find the addition of a 
 comment indicating that a patch has failed on a bot, over the existing 
 indication in the bubble, to be worth the noise it creates.
 
 I propose that we stop allowing the bots to comment, and leave that space 
 for the developers.
 
 - Sam
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Heads up: FALLTHROUGH annotations for switches with fallthroughs

[Joseph Pecoraro]

Hello!

I'm slowly enabling -Wimplicit-fallthrough on projects in the Mac / iOS ports.
http://trac.webkit.org/changeset/162793
http://clang.llvm.org/docs/LanguageExtensions.html#the-clang-fallthrough-attribute

This means that if you write any switch statements with implicit fallthroughs 
it will produce build errors in projects with the warning enabled.

If you're writing a switch with a fallthrough, use the FALLTHROUGH; 
annotation (which expands to [[clang::fallthrough]];) to appease the warning.

The intent of this warning is to catch at compile time any accidental switch 
fallthroughs, and therefore explicitly annotate everywhere a fallthrough was 
intended.

Thanks,
- JoePeck

--

For example. Here is a switch with an implicit fallthrough but no compiler 
recognized annotation:

switch (input) {
case 1:
output -= 5;
// fallthrough
default:
output += 5;
}

When the warning is enabled you will see a build error like:

main.cpp:9:5: warning: unannotated fall-through between switch labels 
[-Wimplicit-fallthrough]
default:
^
main.cpp:9:5: note: insert 'FALLTHROUGH;' to silence this warning
default:
^
FALLTHROUGH; 
main.cpp:9:5: note: insert 'break;' to avoid fall-through
default:
^
break; 

Use FALLTHROUGH; to annotate the fallthrough and build without errors:

switch (input) {
case 1:
output -= 5;
FALLTHROUGH;
default:
output += 5;
}

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

Re: [webkit-dev] Heads up: FALLTHROUGH annotations for switches with fallthroughs

[Joseph Pecoraro]

Nope! If there is no statement between case labels, there will be no warning.

Follow the link for a more complete description of cases:
http://clang.llvm.org/docs/LanguageExtensions.html#the-clang-fallthrough-attribute

- Joe

On Jan 26, 2014, at 10:23 AM, Brady Eidson beid...@apple.com wrote:

 I like this!
 
 Out of curiosity, will it be needed for cases like:
 
 switch (input) {
 case 1:  // fallthrough?
 case 2:
 // Handle both 1 and 2
 break;
 default:
 // default
 }
 
 Thanks,
 ~Brady
 
 On Jan 26, 2014, at 1:41 AM, Joseph Pecoraro pecor...@apple.com wrote:
 
 Hello!
 
 I'm slowly enabling -Wimplicit-fallthrough on projects in the Mac / iOS 
 ports.
 http://trac.webkit.org/changeset/162793
 http://clang.llvm.org/docs/LanguageExtensions.html#the-clang-fallthrough-attribute
 
 This means that if you write any switch statements with implicit 
 fallthroughs it will produce build errors in projects with the warning 
 enabled.
 
 If you're writing a switch with a fallthrough, use the FALLTHROUGH; 
 annotation (which expands to [[clang::fallthrough]];) to appease the warning.
 
 The intent of this warning is to catch at compile time any accidental switch 
 fallthroughs, and therefore explicitly annotate everywhere a fallthrough was 
 intended.
 
 Thanks,
 - JoePeck
 
 --
 
 For example. Here is a switch with an implicit fallthrough but no compiler 
 recognized annotation:
 
 switch (input) {
 case 1:
 output -= 5;
 // fallthrough
 default:
 output += 5;
 }
 
 When the warning is enabled you will see a build error like:
 
 main.cpp:9:5: warning: unannotated fall-through between switch labels 
 [-Wimplicit-fallthrough]
 default:
 ^
 main.cpp:9:5: note: insert 'FALLTHROUGH;' to silence this warning
 default:
 ^
 FALLTHROUGH; 
 main.cpp:9:5: note: insert 'break;' to avoid fall-through
 default:
 ^
 break; 
 
 Use FALLTHROUGH; to annotate the fallthrough and build without errors:
 
 switch (input) {
 case 1:
 output -= 5;
 FALLTHROUGH;
 default:
 output += 5;
 }
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 

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

Re: [webkit-dev] WebKit Remote Web Inspector

[Joseph Pecoraro]

Hello,

Yes, this is possible. There are currently two paths to making Web Inspector 
work across processes.


1. ENABLE(INSPECTOR_SERVER)

Currently enabled by GTK and EFL. The UIProcess process establishes an HTTP 
Web/WebSocket server. The index page is a listing page which advertises 
information about each of the different WebViews that can be inspected. For 
each of these there is a page which fetches the HTML web inspector frontend 
assets (WebInspectorUI) and then establishes a WebSocket connection back to the 
UIProcess to send and receive inspector protocol messages.

Pros:
  - easy to implement and setup
  - a compatible web inspector frontend is downloaded on demand, so it should 
be guarenteed to work
  - debugger could just be another web browser (you will get best results when 
that other browser is a WebKit based browser)
Cons:
  - pull based, debugger needs to fetch an updated listing
  - frontend features can be limited when run in a generic web environment 
(non-native context menus, no copy/paste, no system beep, etc)


2. ENABLE(REMOTE_INSPECTOR)

Currently enabled by Mac and iOS. Very port specific right now. Uses XPC to 
communicate to a middleman process that advertising and helps set up 
connections for the inspector protocol messages.

Pros:
  - push based. As WebViews are created, destroyed, or change, they can 
advertise updates to debuggers
  - using XPC the middleman process can check privileges of each side
Cons:
  - frontend is not downloaded, so it requires having a debugger process with a 
frontend that will work with whatever it is connected to
  - not implemented in other ports, would take port specific work to get this 
path up and running in other ports


If this is just something you want to get up and running to make debugging as a 
developer easier, it sounds like ENABLE(INSPECTOR_SERVER) would work well for 
you. Depending on your port, there should be settings for enabling and 
configuring the inspector server (e.g. port # for the server to listen on) and 
it should be easy to get up and running.

What port are you working on?

- Joe

On Jun 20, 2014, at 4:11 PM, Vienneau, Christopher cvienn...@ea.com wrote:

 Hi,
  
 I’m investigating the possibility of getting access to the “Web Inspector” UI 
 http://trac.webkit.org/wiki/WebInspector#no1 remotely via another 
 browser/process.  This is useful when attempting to debug a page on a device 
 that doesn’t have the same screen real estate as your PC, such as a mobile 
 device.  I’m familiar with “Weinre” 
 http://people.apache.org/~pmuellr/weinre/docs/latest/Home.html which offers 
 many of the features of Web Inspector in a fashion that I’m talking about; 
 but some important elements are missing, such as profiling and java script 
 debugging.  I found “heX” https://github.com/netease-youdao/hex is able to do 
 what I want, but I would like to be able to accomplish the same thing from 
 WebKit itself, since the target platform isn’t on the pc.  Searching through 
 the WebKit source code I can’t find any trace of it having the ability to 
 open a listening port to have a debugging client attach. 
  
 Is such a thing already possible?  The docs, and older mail threads suggested 
 that remote operation was once a goal of Web Inspector, does work continue on 
 this vein? Please offer any suggestions on how this might be accomplished.
  
 Thanks
  
 Chris Vienneau
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] EFL and GTK EWS bots having issues

[Joseph Pecoraro]

It seems the EFL and GTK EWS bots are having trouble for a few days now:
http://webkit-queues.appspot.com

- GTK EWS bot has Unable to build without patch” with:
ninja: error: build.ninja:3225: lexing error

- EFL EWS bot doesn’t seem to be processing patches.

Who would be best to look into these issues? I thought there used to be a list 
of EWS maintainers, but I couldn’t find it.

Having these EWS bots to test CMake build changes is awesome, but with the bots 
down I’m stuck.

- Joe___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WKWebView Inspector in my own app

[Joseph Pecoraro]

 On Aug 11, 2014, at 3:23 AM, Koen Bok k...@madebysofa.com wrote:
 
 I am looking how to show the inspector in my own mac desktop app with 
 WKWebViews.

You are correct that currently the only supported way to inspect a WKWebView is 
through Safari with an entitlement in your app (see the WWDC talk for more 
information).


 I think I need to initialize an XPC or http connection to a WKWebView and 
 pass it to a new inspector instance, and then show it.
 
 Can anyone maybe point me in the right direction?

From a WebKit Internals perspective, you just need to enable WebCore's 
Settings::developerExtrasEnabled setting to get what you want. No XPC/HTTP 
connections necessary.

The WKWebView API allows toggling WebCore's Settings via the WKPreferences 
interface (available on WKWebViewConfiguration).  Nothing currently exists for 
the developer extras setting. It should be easy to add plumbing for a new 
setting to toggle the Developer Extras Enabled setting at least as a private 
API.

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

Re: [webkit-dev] WKWebView Inspector in my own app

[Joseph Pecoraro]

 On Aug 11, 2014, at 12:10 PM, Joseph Pecoraro pecor...@apple.com wrote:
 
 
 On Aug 11, 2014, at 3:23 AM, Koen Bok k...@madebysofa.com 
 mailto:k...@madebysofa.com wrote:
 
 I am looking how to show the inspector in my own mac desktop app with 
 WKWebViews.
 
 You are correct that currently the only supported way to inspect a WKWebView 
 is through Safari with an entitlement in your app (see the WWDC talk for more 
 information).
 
 
 I think I need to initialize an XPC or http connection to a WKWebView and 
 pass it to a new inspector instance, and then show it.
 
 Can anyone maybe point me in the right direction?
 
 From a WebKit Internals perspective, you just need to enable WebCore's 
 Settings::developerExtrasEnabled setting to get what you want. No XPC/HTTP 
 connections necessary.
 
 The WKWebView API allows toggling WebCore's Settings via the WKPreferences 
 interface (available on WKWebViewConfiguration).  Nothing currently exists 
 for the developer extras setting. It should be easy to add plumbing for a new 
 setting to toggle the Developer Extras Enabled setting at least as a private 
 API.

I filed and put a patch up on:
https://webkit.org/b/135811 Add Private WKPreferences API for developer 
extras (show inspector)

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

Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger breakpoint handling (on Wincairo)

[Joseph Pecoraro]

> Here are the simple steps to reproduce it,
> 1.   Launch WinCairo and go to google.com 
> 2.   Open Web inspector and open the script source of any .js script
> 3.   Set a breakpoint anywhere
> 4.   Reload the web page
>  
> What we see is the spinner spinning and never the script source. However, if 
> one presses continue-script-execution from the debugger controls, we get the 
> view back.

Is WinCairo using WebKit1 or WebKit2?

This sounds like a known issue with WebKit1 where the inspector frontend page 
lives in the same process as the inspected page. In this situation pausing a 
page prevents Promise reactions from firing in the inspector frontend page. 
Loading resource content in the frontend depends on Promises. This should not 
be a problem in a WebKit2 world where the inspector frontend page lives in a 
separate process.

- Joe___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger breakpoint handling (on Wincairo)

[Joseph Pecoraro]

I suggest reopening and restarting investigation on:
 Promise reactions in the Inspector page do not 
run when the debugger is paused on the inspected page

The bug already has some analysis. You could use that to verify if your case is 
the same and investigate a fix. Since the time that bug was closed Promises 
have been used in other places in the inspector, so WebKit1 inspection may 
suffer from other more subtle issues with the same cause.

Further communication can happen in the bugzilla bug.

- Joe

> On Oct 2, 2015, at 4:20 PM, Vienneau, Christopher  wrote:
> 
> WinCairo and our port are both WebKit1, so your suggestion sounds quite 
> plausible.  On our port we also hooked up remote WebInpsector but it suffers 
> from the same issue, due to the way its hooked up I think it would be pretty 
> much with WebKit1 way of doing things here too.  Are there any suggestions on 
> how we might verify and workaround this issue?
>  
> Chris
>  
> From: pecor...@apple.com [mailto:pecor...@apple.com] 
> Sent: Friday, October 02, 2015 3:12 PM
> To: Vienneau, Christopher 
> Cc: WebKit Development ; Alex Christensen 
> ; Sharma, Rupali 
> Subject: Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger 
> breakpoint handling (on Wincairo)
>  
> Here are the simple steps to reproduce it,
> 1.   Launch WinCairo and go to google.com 
> 2.   Open Web inspector and open the script source of any .js script
> 3.   Set a breakpoint anywhere
> 4.   Reload the web page
>  
> What we see is the spinner spinning and never the script source. However, if 
> one presses continue-script-execution from the debugger controls, we get the 
> view back.
>  
> Is WinCairo using WebKit1 or WebKit2?
>  
> This sounds like a known issue with WebKit1 where the inspector frontend page 
> lives in the same process as the inspected page. In this situation pausing a 
> page prevents Promise reactions from firing in the inspector frontend page. 
> Loading resource content in the frontend depends on Promises. This should not 
> be a problem in a WebKit2 world where the inspector frontend page lives in a 
> separate process.
>  
> - Joe

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

Re: [webkit-dev] Inspector code

[Joseph Pecoraro]

Whoever hosts the Web Inspector frontend page has the real connection to the 
backend. The host provides an InspectorFrontendHost global object to the 
frontend page that can be used to send messages through that already 
established connection. Likewise when the host wants to trigger operations in 
the frontend page it calls methods on InspectorFrontendAPI.

• The frontend page uses InspectorFrontendHost.sendMessageToBackend to send 
JSON Inspector Protocol messages to the backend. This is never used directly, 
we generate APIs that construct the JSON messages that get sent through this.

• The frontend page receives messages from the backend through 
InspectorFrontendAPI.prototype.dispatchMessageAsync. Again generated APIs route 
these incoming messages to more convenient places such as domain observers or 
callbacks for earlier commands.

On the native side you can look at WebInspectorProxy::sendMessageToBackend to 
see how the frontend host's native connection to the backend is used and 
related code to see how it was established. Ultimately only a 
Inspector::FrontendChannel needs to be provided to WebCore's 
InspectorController to establish a backend <-> frontend connection. So you can 
set a breakpoint on WebCore::InspectorController::connectFrontend and see how / 
where it gets triggered. The common case in WebKit2 happens under 
WebKit::WebInspector::show.

- Joe

> On Feb 24, 2017, at 5:33 AM, kwadwo amankwa  wrote:
> 
> Hi all,
> 
> Just studying the Inspector code and interested to know how(or where) the 
> Inspector front-end connects to the backend.
> 
> cheers
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] REQUEST_ANIMATION_FRAME on all ports?

[Joseph Pecoraro]

I also like the idea that we should remove flags for core web features that 
have been stable for a while.

There were no objections raise on this thread to remove the 
REQUEST_ANIMATION_FRAME flag.

Patch up on:
https://bugs.webkit.org/show_bug.cgi?id=156980 


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

Re: [webkit-dev] Another WPT bite

[Joseph Pecoraro]

> On May 12, 2017, at 2:39 PM, Ryosuke Niwa  wrote:
> 
> On Fri, May 12, 2017 at 12:04 PM, Alexey Proskuryakov  > wrote:
> 
>> We don't have a concept of "first class", but I hope that when choosing
>> between looking into a simple test that was added for a known important bug,
>> and looking into an imported test whose importance is unclear, any WebKit
>> engineer will pick the former. And since no one can fix all the things, such
>> prioritization makes imported tests less effective.
> 
> This is absolutely not how I operate at all. Since almost all custom
> elements and shadow DOM API tests I wrote are written using
> testharness.js and upstreamed to web-platform-tests, they have been
> deleted from LayoutTests/fast/shadow-dom &
> LayoutTests/fast/custom-elements.
> 
> As such, if any new shadow DOM or custom elements tests under
> LayoutTests/imported/ start to fail, then we must fix them since we
> idon'thave any other test coverage.


On the topic of LayoutTest/imported tests, can someone describe the current 
process of working with LayoutTest/imported?

How do we handle a broken test in our tree?

• Do we modify our expectations?
- If so, how do we remember to change the expectations in a later 
import?

• Do we modify the test? More generally, are any modifications allowed inside 
of LayoutTest/imported?
- If so, how do we track the fact that we have modifications so that a 
later import doesn't just wipe out our changes?
- Without tooling, is the person who modifies the test responsible for 
making an upstream pull request?

How do we handle a new imported test that WebKit fails?

To avoid bots being red this test will end up getting skipped or marked as 
flakey.

How do we ensure this actually gets addressed and not ignored / forgotten about?

To make upstream changes someone has to make a pull-request:

I've had some upstream patches reviewed immediately and others are still in 
review after 3+ months.

In an earlier webkit-dev email Youenn mentioned:
https://lists.webkit.org/pipermail/webkit-dev/2017-April/028932.html

> As done by other browser teams, a test that is reviewed in WebKit bugzilla and
> landed in WebKit can be readily merged into WPT without additional review
> (although additional review is always great!).


I don't have commit access to the WPT GitHub. So ultimately I still have to go 
through another review to get my pull requests accepted.

- Joe

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

[webkit-dev] Proposal: Remove Vibration API

[Joseph Pecoraro]

There is code in the tree for the Vibration API guarded by ENABLE(VIBRATION). I 
propose we remove it:
 Remove Vibration API

There have been concerns that the Vibration API can be used for fingerprinting 
and has the potential for abuse by web content:
>
>

Currently this feature is not enabled by any port, so it is unmaintained. 
Generally that would be enough to remove the code unless a port wishes to 
enable and maintain the feature.

Does any port intend to enable and maintain this feature?

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

Re: [webkit-dev] dump-class-layout script not working

[Joseph Pecoraro]

> On Nov 4, 2018, at 3:43 AM, Frank Jaeger  wrote:
> 
> Hello. First of all I'm really sorry if this is the wrong mailing list to 
> post to, webkit-help would have probably been better but it doesn't seem very 
> active.
> 
> I run into some problems while trying to use the dump-class-layout script 
> (found in Tools/Scripts/). I built WebKit using the build-webkit script with 
> the --debug flag.
> 
> After building, I tried to run the dump-class-layout script with the 
> following arguments:
> 
> ./Tools/Scripts/dump-class-layout --architecture=x86_64 -c Debug 
> JavaScriptCore JSString
> 
> I also tried different frameworks and classes. The script always fails 
> telling me that "no type matches x in y" where x is the class name I used in 
> the run and y is the framework name.
> 
> Why is this happening? The script is correctly finding the built and 
> symbolicated framework image, so why is it not working properly? Thanks in 
> advance.

This just worked for me on Mojave.

$ ./Tools/Scripts/dump-class-layout --architecture=x86_64 -c Debug 
JavaScriptCore JSString
  +0 < 24> JSString
  +0 <  8> JSC::JSCell JSC::JSCell
  +0 <  1> JSC::HeapCell JSC::HeapCell
  +0 <  4>   JSC::StructureID m_structureID
  +4 <  1>   JSC::IndexingType m_indexingTypeAndMisc
  +5 <  1>   JSC::JSType m_type
  +6 <  1>   JSC::TypeInfo::InlineTypeFlags m_flags
  +7 <  1>   JSC::CellState m_cellState
  +8 <  4>   unsigned int m_length
 +12 <  2>   uint16_t m_flags
 +14 <  2>   
 +16 <  8> WTF::String m_value
 +16 <  8> WTF::RefPtr > m_impl
 +16 <  8>   WTF::DumbPtrTraits::StorageType m_ptr
Total byte size: 24
Total pad bytes: 2
Padding percentage: 8.33 %

Could you show your exact output?

Perhaps opening a Bugzilla bug and putting the details there would be best. I’d 
be interested to know your version of Xcode/lldb (lldb --version, xcodebuild 
-version).

- Joe

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

Re: [webkit-dev] Can we remove XXX.order files in the tree

[Joseph Pecoraro]

I put up patches a few year ago:
 [Cocoa] Remove or update order files

It was approved at the time, but I was asked to measure performance and I'm 
still not sure how to do that.

I'm still in favor of removing them!

- Joe

> On Oct 17, 2019, at 3:06 PM, Saam Barati  wrote:
> 
> Can we measure the performance impact of doing this?
> 
> If it's neutral, I think we should remove it.
> 
> - Saam
> 
>> On Oct 17, 2019, at 3:05 PM, Yusuke Suzuki  wrote:
>> 
>> Hello WebKittens!
>> 
>> Our XXX.order file (e.g. JavaScriptCore.order) is not updated so long. The 
>> content is already stale, and I think this is no longer effective.
>> Can we just remove these XXX.order files?
>> 
>> -Yusuke
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Accidental binary bloating via C/C++ class/struct + Objective-C

[Joseph Pecoraro]

This is a great idea!

- Joe

> On Jan 13, 2020, at 5:52 PM, Yusuke Suzuki  wrote:
> 
> Hello WebKittens,
> 
> I recently striped 830KB binary size in WebKit just by using a work-around.
> This email describes what happened so far, to prevent from happening again.
> 
> ## Problem
> 
> When C/C++ struct/class is included in field types and method types in 
> Objective-C, Objective-C compiler puts type-enconding-string which gathers 
> type information one-leve deep for C/C++ struct/class if
> 
> 1. The type is a pointer to C/C++ struct/class
> 2. The type is a value of C/C++ struct/class
> 3. The type is a reference to C/C++ struct/class
> 
> However, our WebKit C/C++ struct/class is typically very complex type using a 
> lot of templates. Unfortunately, Objective-C compiler includes expanded 
> template definition as a string and adds it as a type-enconding-string into 
> the release binary!
> 
> For example, https://trac.webkit.org/changeset/254152/webkit 
>  is removing JSC::VM& from 
> Objective-C signature, and it reduces 200KB binary size!
> Another example is https://trac.webkit.org/changeset/254241/webkit 
> , which removes a lot of 
> WebCore::WebView* etc. from Objective-C method signature, and reduces 630KB 
> binary.
> 
> ## Solution for now
> 
> We can purge type-encoding-string if we use Objective-C NS_DIRECT feature 
> (which makes Objective-C function as C function calling convention, removing 
> metadata).
> However, this does not work universally: with NS_DIRECT, Objective-C override 
> does not work. This means we need to be extra-careful when using it.
> 
> So, as a simple, but effective work-around, in the above patch, we introduced 
> NakedRef / NakedPtr. This is basically raw pointer / raw reference to 
> T, with a wrapper class.
> This leverages the behavior of Objective-C compiler’s mechanism “one-level 
> deep type information collection”. Since NakedRef / NakedPtr introduces 
> one-level deep field,
> Objective-C compiler does not collect the type information of T if 
> NakedPtr is included in the fields / signatures, while the compiler 
> collects information when T* is used.
> 
> So, if you are using T& / T* C/C++ struct/class in Objective-C, let’s convert 
> it to NakedRef / NakedPtr. Then you could save much binary size 
> immediately without causing any performance problem.
> 
> ## Future work
> 
> We would like to avoid including such types accidentally in Objective-C. We 
> should introduce build-time hook script which detects such a thing.
> I uploaded the PoC script in https://bugs.webkit.org/show_bug.cgi?id=205968 
> , and I’m personally planning 
> to introduce such a hook into a part of build process.
> 
> 
> -Yusuke
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Caio Lima is now a WebKit reviewer

[Joseph Pecoraro via webkit-dev]

Congrats Caio!!

- Joe

> On Mar 18, 2021, at 3:42 PM, Saam Barati via webkit-dev 
>  wrote:
> 
> Hi folks,
> 
> I'm happy to announce that Caio Lima is now a WebKit reviewer. Send your 
> JavaScriptCore reviews his way!
> 
> Congrats, Caio.
> 
> - Saam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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