Re: [webkit-dev] WebKit Transition to Git

2020-10-14 Thread Adrien Destugues
> 3. Changelog
> I don’t feel it's a big problem to write ChangeLog file.
> Of course, this is tired thing but I don’t have a strong alternative
> after reading this thread.
> 
> However the current `prepare-Changelog` script does not fit with a
> branch -based workflow on Git, I feel. There is a room to polish on
> this Git migration.
> 
> For example, I’d like to specify a branch as my working set in my
> local machine, instead of commit or staged changes.
> 
> Ordinary, I do these flows but it’s a bit tired…. (if you know more
> good ways, could you tell me!):
> 
> 1. Run `prepare-Changelog`
> 2. Format ChangeLog file and remove duplicated entries added by _steps 1_.
> 3. Fuse new changes into a single patch by `git add . && git commit
> --ammend` or `git commit --fixup HEAD && git rebase master -i
> --autosquash`
> 4. Upload patches by `webkit-patch upload -g HEAD`
> 
> I don’t have an objection that we merge a squashed patch into trunk to
> simplify the history but we would have some chance to improve the script.
> 

The original goal mentionned at the start of the thread was encouraging
more people to contribute to WebKit. From that side, what's important is
trying to retain a patch submission workflow that's standardized. That can
be github/gitlab style pull requests, or Gerrit which is a different one.
There are probably others.

If the workflow for submitting patches requires writing a changelog file,
or other similar custom operations, I think that's more likely to turn
potential contributors away (I can only speak for myself, here, of course).
Even if you automate it with a script, people will have to remember to
use the script. Then it doesn't matter if you use Git or Github or some
other tool under the hood: the patch submission process is a custom one.

Starting from there, the question is more:

Which of these existing workflows is more suitable?

How much can we tweak them (with bots on Github, plugins
on Gerrit, or pre-commit/pre-push hooks on developer machines, for example)
to make them better fit the existing things that will probably be kept?
(I guess Apple internal bugtracker, possibly bugzilla as well, maybe some
parts of the existing build infrastructure and builder machines?).

Can these changes to the workflow be done and documented so that existing
Git (and Github/Gitlab/Gerrit/...) users can handle them easily?

-- 
Adrien.

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-05 Thread Adrien Destugues
> One thing to take into account is that WebKit's repository is big and
> public GitHub/GitLab prevent creating large repository by default. This
> means it might not be possible for contributors to actually fork
> WebKit's repository on their account and then create a pull request
> (which is the standard way IIUC). Instead, we would probably end up
> doing like web-platform-tests and give contributors the permission to
> create branches to the WebKit account and make Pull Request to the
> master branch. Probably, we should forbid people to commit to the master
> branch directly (I think someone broke WPT's master branch that way last
> year)...
> 
> Similarly, public GitHub/GitLab prevent very large files by default.
> Hopefully, this does not happen in WebKit (we should definitely add a
> hook to prevent someone to land a big file) but for example that mistake
> happened in Chromium last year (
> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/tSOmIfXAP2s/m/H07SmWIoCgAJ
> ) and this broke the sync of their GitHub mirror.

There is already a mirror of the existing WebKit repository on Github, and 
there are
about 2000 forks of it already [1]. At least the Haiku version of WebKit is 
maintained this
way, and had no problems with Github so far. So this shouldn't be a problem?

[1] https://github.com/WebKit/webkit/network/members

-- 
Adrien.

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-03 Thread Adrien Destugues
On Sat, Oct 03, 2020 at 08:43:40PM +0300, Konstantin Tokarev wrote:
> >>  Gerrit accepts GitHub and other OAuth providers as well, so that's not a
> >>  problem. We have been using this for Haiku code reviews for a few years
> >>  now, and interestingly we got some complaints from people who don't want
> >>  to have a Github account (for various reasons) and won't use our code
> >>  review tool because of that.
> >
> > What are the reasons why people don't want to have a GitHub account? I 
> > wonder if that's somehow a different kind of barrier to entry to be 
> > concerned about.
> 
> Maybe because it's owned by Microsoft, which is an enemy of all living things 
> and
> basically are an embassy of Devil on Earth (no).

Yes that's why I didn't elaborate much. Whichever tool you pick, there
will always be people unhappy about it.

In the case of Github, reasons I've heard of are (not that I agree or
disagree with anything here, that's not the point):
- It's not open source
- It's owned by Microsoft
- It has contracts with the ICE in the USA
  
(https://www.theatlantic.com/technology/archive/2020/01/ice-contract-github-sparks-developer-protests/604339/)
- It's too big and making a large part of open source work centralized in one
  place (mainly from people who already suffered from problems with Sourceforge
  or Google Code Project Hosting in the past, I guess)

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-03 Thread Adrien Destugues
On Fri, Oct 02, 2020 at 07:05:21PM -0500, Michael Catanzaro wrote:
> > I realize that Gerrit might not integrate at all with hosting the repo
> > on Github, but has any thought been given to this aspect of the
> > transition?
> 
> That sounds like it would be a significant barrier to contribution, and
> frankly defeat the point of switching. If we have serious concerns with
> GitHub's code review functionality (which, again, I'm not familiar with),
> then we should just use GitLab and have everything in one place. (GitLab
> accepts GitHub logins via OAuth, both on gitlab.com and self-hosted
> instances, so the barrier to contributing remains low either way.)

Gerrit accepts GitHub and other OAuth providers as well, so that's not a
problem. We have been using this for Haiku code reviews for a few years
now, and interestingly we got some complaints from people who don't want
to have a Github account (for various reasons) and won't use our code
review tool because of that.

I think the integration referred to was rather in terms of having
reviews synchronized between Gerrit and Github pull requests, which is
also possible, but I think if the point is to use Github, it doesn't
work this way: if your workflow is too different from the standard way
to use Github, people will still be confused by it and it will still be
a barrier to contribution.

I think having to create an account on a website isn't the main thing
preventing people to contribute anyway? It's more about having to use
project-specific tools to prepare the patch for submission (in the case
of WebKit, having to write the commit message in the Changelog file, for
example).

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-03 Thread Adrien Destugues
> Github's code review UI has a couple of feature gaps in my opinion. It's
> difficult to look at earlier versions of the pull request, in particular to
> verify that issues found during code review have been fixed. I remember it
> also being difficult to figure out whether all comments on earlier versions
> have been addressed.
> 
> Gerrit code review has worked well in my experience. It explicitly manages
> different versions of the same patch set, and prominently shows whether all
> code review comments have been addressed.
> 
> I realize that Gerrit might not integrate at all with hosting the repo on
> Github, but has any thought been given to this aspect of the transition?

I agree, not only because I think Gerrit is a better tool for code
review, but also because with Git, the tool you chose has a large impact
on the way you work. Git provides a framework, and both Github and
Gerrit use this tool to implement quite different workflows and way to
manage code review and patches.

I think that is possibly more important than picking an hosting place
based only on its popularity, because if the tool doesn't match the way
you want to work, you will workaround it and the situation will not be a
lot better than it is now: you will end up with custom scripts to help
sending patches the correct way, and for contributors it won't be
anything like contributing to another github hosted repo anyway.

That being said, in my case I can say that if the patch submission
process is simplified by using standard git tools, I'm indeed more
likely to consider trying to upstream the Haiku port or at least some
parts of our changes. In the current situation it indeed seems easier to
maintain our fork on our side instead.

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


Re: [webkit-dev] Introducing a minimum ICU version for WebKit

2020-04-09 Thread Adrien Destugues
>Also, sadly ICU does not maintain a stable API or ABI. So every 
>application and library using ICU would need to be rebuilt and updated 
>at the same time. Then the update would break any custom software that 
>users have using the system ICU. Such an update would go badly... 
>probably would wind up in tech news once people notice the breakage.
>

Icu can be built with all its abi inside a different namespace for each 
version, so that multiple versions can live side by side and even be loaded in 
the same process without conflicts. Are Linux distros not packaging it that 
way? It makes updates easier as the transition can be made more gradually, at 
least.

And it would make it possible to ship a newer icu with webkit, while not 
risking conflicts with the system provided one.

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


Re: [webkit-dev] Moving to Python 3

2019-07-13 Thread Adrien Destugues

>I don’t think anyone is arguing that we’d eventually need to move to
>Python3. I’m arguing that it’s not okay to require random WebKit
>contributor to know some obscure python insanity to install Python 3,
>or
>have a script that installs Python 3 and breaks all other python
>scripts in
>the system.
>
>

Python3 would normally install a "python3" executable that's independant from 
the "python" one from Python2? It's fairly common to have these side by side 
precisely because they are not compatible.

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


Re: [webkit-dev] Help regarding rendering in webkit2 port of haiku

2019-06-10 Thread Adrien Destugues
On Mon, Jun 10, 2019 at 09:37:06AM +0300, Noam Rosenthal wrote:
> ~ (reposting from webkit email)

Hi,

I should pprobably give a little more context here, as the maintainer of
the WebKitLegacy port for Haiku.

Our main concern, as Rajagopalan mentionned, is that Haiku does not have
any rendering acceleration, it's all done in software. We do have OpenGL
but it may not be the best choice for rendering, because of this.

As a result, we had to find a way to get things working, in what is
indeed a little unusual setup. Currently we have coordinated graphics
disabled:

Source/cmake/OptionsHaiku.cmake:add_definitions(-DUSE_COORDINATED_GRAPHICS=0)

We do however have a software rendering version of texture mapper, that
was removed from webkit long time ago but we kept because we didn't want
to use the OpenGL version. I have not reviewed its use recently, maybe
it is not needed anymore.

Another limitation we hit on some websites is that it is not possible
for us to create too many drawable offscreen bitmaps. There is a
system-wide limit of 4096, which can be hit rather easily on Google
Maps, for example. So we will probably need a way to limit the use of
drawable bitmaps when possible. Maybe coordinated graphics would help
here, if it allows to share a single drawing context and bitmap, rather
than creating a separate one for each rendering layer.

On the way drawing works for us: the drawing primitives are all
implemented in our display server, there is no rendering done client
side in webkit processes. This means the display server has a pointer to
the bitmap data already, and ideally it would be able to pass this from
one application to another without needing to copy all the data. We may
need to make some changes to our display server to allow this, but
that's fine (it's the nice thing about Haiku, if we need to change
something in the OS, we can do that easily).

Now we have to find out if coordinated graphics or some other way to do
things makes sense, and for this we have to understand how the rendering
work is split between web process and ui process, and what kind of data
they expect to exchange between them. Especially in our case where the
bitmap data is in fact already shared with the OS display server, so if
UI process does not do any drawing by itself, it doesn't actually need
to access the data.

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


Re: [webkit-dev] Queries regarding few Components in webkit

2019-03-17 Thread Adrien Destugues
Hi,

We are already in contact and the work will indeed be based on the Haiku fork. 
While I can mentor the Haiku side of the project, I think it is a good idea to 
rely on you all for the WebKit side of things.

I hope this will allow us toget one second developer working on the Haiku port, 
so I can do more than just keeping our port up to date.

On the current state of our port: the network backend is working, it's not 
perfect but we don't currently plan switching back to curl. The webkit2 work is 
only some very early steps and has stayed untouched for the past 4 years, so 
there may not be this much to recover from it. The Webkitlegacy parts are used 
in production, but we have not made them a public api, so that we can switch to 
webkit2 more easily (only our browser will need an update)

Thanks for your support and answering Rajagopalan's questions!

-- 
Adrien/PulkoMandy
Haiku port maintainer
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Regarding problem in building webkit2

2019-02-25 Thread Adrien Destugues
Hi,

The Haiku ports uses its own implementation of HTTP, relying on the
libraries provided in Haiku for that. We will probably not be switching
back to curl.

However, we have used only WebKitLegacy so far so it is expected that
some parts of our network backend will be missing (everything that was
not used by WebKitLegacy).

-- 
Adrien.

On Mon, Feb 25, 2019 at 06:30:11PM +, don.olmst...@sony.com wrote:
> We've put a large amount of work on the cURL networking layer and are 
> continuing to improve it. It's used by both the WinCairo and PlayStation port 
> so it works cross platform.
> 
> I'm not familiar with the stack on Haiku but it would require OpenSSL, we use 
> LibreSSL in both, nghttp2 for HTTP/2, and libpsl for Public Suffix List 
> support. You can also compile with brotli support as well for better 
> compression over zlib.
> 
> -Original Message-
> From: webkit-dev  On Behalf Of 
> Konstantin Tokarev
> Sent: Monday, February 25, 2019 4:25 AM
> To: Rajagopalan Gangadharan ; 
> webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] Regarding problem in building webkit2
> 
> 
> 
> 25.02.2019, 14:06, "Rajagopalan Gangadharan" :
> > Hello,
> >
> > I am trying to build webkit for haiku and I stumbled upon an error
> >
> > The error is in “Source\WebKit\UIProcess\WebsiteData\WebsiteDataStore.cpp” 
> > line 2080 says about missing platformSetNetworkParameters function and I 
> > saw it was defined for CURL and SOUP only. Should I use the function 
> > defined under them or should I write it to be haiku specific(platform 
> > specific) if so what should be the contents of it. Thank you!
> 
> It depends on how your network stack works. In order to reduce maintainance 
> cost you should consider using network stack supported by upstream, i.e. soup 
> or curl
> 
> --
> Regards,
> Konstantin
> ___
> 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] Encoding and decoding ProcessID

2019-02-24 Thread Adrien Destugues
On Sun, Feb 24, 2019 at 10:52:53AM -0800, Sam Weinig wrote:
> Hi Adrien,
> 
> Would you mind adding the compiler output when this happens? I’d like to see 
> exactly what the error you are seeing is.

Sorry, here is the compiler output:
http://paste.debian.net/1069971

In file included from 
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp: In static 
member function 'static bool 
WebKit::NetworkResourceLoadParameters::decode(IPC::Decoder&, 
WebKit::NetworkResourceLoadParameters&)':
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:41: 
error: no matching function for call to 'IPC::Decoder::decode(WTF::ProcessID&)'
 if (!decoder.decode(result.parentPID))
 ^
In file included from 
../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
 from 
../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
 from 
../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
 from 
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
../../Source/WebKit/Platform/IPC/Decoder.h:80:10: note: candidate: bool 
IPC::Decoder::decode(bool&) 
 bool decode(bool&);
  ^~
../../Source/WebKit/Platform/IPC/Decoder.h:80:10: note:   conversion of 
argument 1 would be ill-formed:
In file included from 
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32: 
error: cannot bind non-const lvalue reference of type 'bool&' to an rvalue of 
type 'bool'
 if (!decoder.decode(result.parentPID))
 ~~~^
In file included from 
../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
 from 
../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
 from 
../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
 from 
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
../../Source/WebKit/Platform/IPC/Decoder.h:82:10: note: candidate: bool 
IPC::Decoder::decode(uint8_t&) 
 bool decode(uint8_t&);
  ^~
../../Source/WebKit/Platform/IPC/Decoder.h:82:10: note:   conversion of 
argument 1 would be ill-formed:
In file included from 
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32: 
error: cannot bind non-const lvalue reference of type 'uint8_t& {aka unsigned 
char&}' to an rvalue of type 'uint8_t {aka unsigned char}'
 if (!decoder.decode(result.parentPID))
 ~~~^
In file included from 
../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
 from 
../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
 from 
../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
 from 
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
../../Source/WebKit/Platform/IPC/Decoder.h:84:10: note: candidate: bool 
IPC::Decoder::decode(uint16_t&) 
 bool decode(uint16_t&);
  ^~
../../Source/WebKit/Platform/IPC/Decoder.h:84:10: note:   conversion of 
argument 1 would be ill-formed:
In file included from 
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32: 
error: cannot bind non-const lvalue reference of type 'uint16_t& {aka short 
unsigned int&}' to an rvalue of type 'uint16_t {aka short unsigned int}'
 if (!decoder.decode(result.parentPID))
 ~~~^
In file included from 
../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
 from 
../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
 from 
../../Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:29,
 from 
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:1:
../../Source/WebKit/Platform/IPC/Decoder.h:86:10: note: candidate: bool 
IPC::Decoder::decode(uint32_t&) 
 bool decode(uint32_t&);
  ^~
../../Source/WebKit/Platform/IPC/Decoder.h:86:10: note:   conversion of 
argument 1 would be ill-formed:
In file included from 
DerivedSources/WebKit/unified-sources/UnifiedSource-72468c22-2.cpp:5:0:
../../Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:117:32: 
error: cannot bind non-const lvalue reference of type 'uint32_t& {aka unsigned 
int&}' to an rvalue of type 'uint32_t {aka unsigned int}'
 if (!decoder.decode(result.parentPID))
 ~~~^
In file included from 
../../Source/WebKit/NetworkProcess/Downloads/DownloadID.h:30:0,
 from 
../../Source/WebKit/NetworkProcess/Downloads/Download.h:28,
 from 

[webkit-dev] Encoding and decoding ProcessID

2019-02-24 Thread Adrien Destugues
Hi there,

We are finally starting to look into moving the Haiku port to WebKit2.

We have hit one little problem I'm not sure how to solve. Our pid_t on
32bit Haiku is declared as a signed long integer (this is for legacy
reasons and not something we can fix easily). Our uint32_t is a signed
integer (not long). This creates a compilation error when using pid_t
with IPC::Encoder, because none of the encode() functions match when
trying to pass a pid_t in our case.

Our options seems to be:
- Cast pid_t to int32_t when encoding it. I fear this would break other
  platforms if they decide to use a 64bit pid_t, for example
- Add an encode(pid_t) to the IPC::Encoder. I fear on other platforms it
  would complain that this is the same as encode(int32_t) and break the
  build
- Define WTF::ProcessID as int32_t instead of pid_t, which I think could
  work, afte rfixing some compiler warnings (we will need to cast back
  to pid_t when passing it to OS functions, I think)

What do you think about it?

one example where encoding a pid is
Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp

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


Re: [webkit-dev] WebKit opengl

2017-08-02 Thread Adrien Destugues
2017-08-02 14:43 GMT+02:00 Gustavo Sverzut Barbieri <barbi...@profusion.mobi>:

>> You are not going to get WebKit working with OpenGLES 1.1 unless you have an 
>> experienced engineer making large modifications to the source code. Instead, 
>> you should just turn off OpenGL/OpenGLES support. Just build with 
>> -DENABLE_OPENGL=OFF. It is optional, you just lose hardware acceleration. 
>> You should hopefully have no trouble with this.
>>
>> If you have a requirement to use OpenGLES regardless, then you may need to 
>> reevaluate the feasibility of your project.
>
> Indeed... we did such port for a customer based on WebKit-EFL (now
> out-of-tree) and it worked, but was a major pain to get there due
> CoordinatedGraphics and TextureMapper being heavy on GL calls...
> however in our case it was software rendering only, no GL at all.

The Haiku port also uses no OpenGL. I have versions of
CoordinatedGraphics and TextureMapper extracted from old verisons of
WebKit which I maintain with the port (TextureMapperImageBuffer is the
entry point for that):
https://github.com/haiku/webkit/blob/rebased/Source/WebCore/platform/graphics/texmap/TextureMapperImageBuffer.cpp

The commit which restores this may serve as a reference (but may not
apply directly to current sources):
https://github.com/haiku/webkit/commit/966df671f60cc716233952c5e80c5fd52d6ce785

-- 
Adrien Destugues / PulkoMandy
http://pulkomandy.tk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

2017-08-01 Thread Adrien Destugues
> Some others I see:
>
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE
> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO

At least these are still not implemented in the Haiku port. I know we
are not an upstream port anymore and have little chance of being again
as I'm slowly trying to catch up with the lates 1.5 years of
development in WebKit. But having to implement all of these would
delay my work even more.

As usual, I don't want the Haiku port to pull WebKit backwards, and I
do plan to implement some of these at some point. However, being able
to disable them at least for some time lets me work on other, more
important aspects of the port first.

If the compile time flags are too annoying for that, maybe an
alternative would be to provide stub implementations, but then support
for these features should still not be advertised to webpages if the
port really doesn't support them.

--
Adrien Destugues / PulkoMandy
http://pulkomandy.tk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev