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

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] 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] 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] 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] 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

[webkit-dev] Settings and Testing (Settings, RuntimeEnabledFeatures, WebPreferences)

[Joseph Pecoraro]

Toggling settings in tests is a confusing area, with multiple (sometimes 
conflicting) ways to modify settings.

After cleaning things up a bit in r211006 I wanted to document my understanding 
of the patterns I see right now. Much of this was new to me so others may find 
it useful.

Different Types of Settings:

• RuntimeEnabledFeatures (WebCore)
- Should be for features that have Web Exposed APIs that will only be exposed 
if the feature is enabled
- Should be for features that must be toggled before a page has loaded, since 
after a page load may be too late for EnabledAtRuntime bindings

• Settings (WebCore)
- All other settings that change engine behavior
- Okay to toggle at any time and WebCore often respects the setting immediately

• WebPreferences (WebKit, WebKit2)
- API level Toggles for the above settings
- Toggles for WebKit level behavior (e.g. Tabbing between links behavior)
- Ports may have different default values for features

Policies for Settings in LayoutTests:

• TestRunners (WebKitTestRunner / DumpRenderTree)
- Should set up a consistent environment before each test
- Ports have different defaults, so having TestRunner make things 
consistent seems reasonable
- WTR: TestController::resetPreferencesToConsistentValues
- DRT: resetWebPreferencesToConsistentValues
- Should enable Experimental features for tests
- Since we allow users to enable these features they should be enabled 
and get maximum testing
- WTR: WKPreferencesEnableAllExperimentalFeatures
- DRT: enableExperimentalFeatures

• If a test wants to change a Setting:
- Use: internals.settings.setFoo(value);
- Settings in Settings.in are autogenerated, others are added to 
InternalSettings as needed
- InternalSettings handles resetting modifications before the next test

• If a test wants to change a RuntimeEnabledFeature:
- No set pattern.
- Some tests use internals.settings but this seems inappropriate, since the 
page has already loaded
- Some tests use the special comment syntax parsed by TestRunners; this makes 
sense, but would not be good for imported tests

• If a test wants to change a WebPreference / WebKit level setting:
- Use: testRunner.someMethod(value);
- Avoid: testRunner.overridePreference(preferenceKey, value);
- TestRunners should reset these back to a consistent value before the next test

Let me know if you think anything is inaccurate or if you have ideas to 
simplify / improve.

- Joe___
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] [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] [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] WKWebView Inspector in my own app

[Joseph Pecoraro]

> On Aug 11, 2014, at 12:10 PM, Joseph Pecoraro  wrote:
> 
> 
>> On Aug 11, 2014, at 3:23 AM, Koen Bok > <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] WKWebView Inspector in my own app

[Joseph Pecoraro]

> On Aug 11, 2014, at 3:23 AM, Koen Bok  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

[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:


- 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] 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  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

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  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  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

[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.



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] 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  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  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  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  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

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  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] ChangeLog format

[Joseph Pecoraro]

On Aug 22, 2013, at 12:46 AM, Carlos Garcia Campos  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  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  Speed up moving cursor/selection up or 
down past non-rendered elements.
6c326ac  [Qt] Fix 
tst_QObjectBridge::connectAndDisconnect() fail
381c093  Chrome::client() should return a 
reference.
f183c4b  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  [Qt] Build fix (broken since r154257).
d3ac166  Clean up StyleElement
5c403bd  Add toSVGStopElement(Node* node) to 
clean-up a static_cast
508cc36  Introduce toSVGAnimateElement(), and use 
it
db5024b  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] 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.
 Web Inspector: Remote debugging meta-bug
https://docs.google.com/document/edit?id=1d_N-OIb3UztuC-_g0piXsIIdp89HnMcDk-uSQ8uamW4&hl=en&authkey=CIf48O4J&pli=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:
 Web Inspector: Remote Web Inspector support for 
QtWebKit [Already Landed]
 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] 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] 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] 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] 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] 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] Documenting common null pointer errors

[Joseph Pecoraro]

On Aug 11, 2009, at 6: 03PM, Adam Barth wrote:

Would it be useful to have a diagram of the major
objects (Page, Frame, DOMWindow, Document, etc) somewhere on
webkit.org that shows their relation, which links can be null, and
which objects change / are preserved during navigation?


I would find this very, very useful to both work with and learn from.   
As it is I can't find any documentation, other then previous patches  
and the code itself, about this kind of information.


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

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