On 03/07/15 10:47, Ryosuke Niwa wrote:
> On Fri, Jul 3, 2015 at 2:32 AM, Mario Sanchez Prada [...]
> FWIW, I've tried reducing the scope of this flag to bmalloc but the crash
> was still there. However, passing it instead for WebCore only did "fix"
> the
>
On 02/07/15 12:11, Mario Sanchez Prada wrote:
> [...]
> If you check my last comments in there, you will see that I found out that
> passing -fno-tree-sra to gcc while compiling would reliably prevent the
> crash from happening, both in my use case and when using the URL above.
>
Hi all,
As I already reported last week in webkit-gtk[1], I've been reliably seeing
a crash in bmalloc lately in my 32bit Linux system every single time I run a
specific Webkit-based app, after upgrading from WebKitGTK+ 2.6.2 to 2.8.3.
See below and excerpt of the best backtrace I could get (see
Hi Jarek,
> -Original Message-
> From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
> boun...@lists.webkit.org] On Behalf Of Jarek Czekalski
> Sent: 03 May 2014 08:35
> To: webkit-dev@lists.webkit.org
> Subject: [webkit-dev] why these tests are still marked Failure? r148002
>
>
Hi all,
I encountered today while trying to build WebKitGTK+ in my old Ubuntu 12.10
box: my compilation failed at
Source/WebCore/Modules/webdatabase/SQLCallbackWrapper.h:79:91 with the
following error:
error: expression ' = ' is not
a constant-expression
The offending snippet of code is
Well deserved. Congratulations!
Mario
> -Original Message-
> From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
> boun...@lists.webkit.org] On Behalf Of Philippe Normand
> Sent: 12 February 2014 23:20
> To: WebKit Development
> Subject: [webkit-dev] Sergio Villar Senin is now a
> [...]
> It seems that for this to be useful for ATs,
> you'd have to iterate every object in your canvas
> and call at least drawCustomFocusRing once. Then
> when the item actually did become focused, you'd
> have to call drawSystemFocusRing.
>
> I don't know what others think, but I think
> acc
Hi,
> [.]
> > The feature does not seem very invasive so if some people really
> > invest time in maturing this, it could be worth experimenting
> > with this and provide feedback to the W3C working group.
> > I think everything should be behind a feature flag, and have the
> > -webkit- prefix. As
Hy Kyounga,
> From: Kyounga Ra [mailto:kyounga...@gmail.com]
> [...]
> Hi Mario,
>
> Thanks for your kind comments in detail.
You're welcome. Thanks to you for your patch and doing this work in the
first place!
> I would be very thankful for you to do that work (using/maintaining this
feature)
Hi Antonio,
> -Original Message-
> From: toniki...@gmail.com [mailto:toniki...@gmail.com] On Behalf Of
> Antonio Gomes
> [...]
> Ah, thanks for clarifying. That changes the scenario then. Question is
> back to open: is there any port that would be willing to have this
> feature's build fla
and probably
re-writting the part based on the now called DeprecatedStyleBuilder which,
according to r148363, should not be used to add new properties since a while
ago.
Thanks for your reply,
Mario
[1] http://trac.webkit.org/changeset/148363
> -Kyounga
>
> > 2013/7/25 Mario Sanchez Pr
Hi,
For the sake of completeness, I'd like to mention that this feature is also
used in the Hbbtv browser shipped with Samsung TVs, as Giuseppe Pascale from
Opera already pointed out in a recent discussion[1].
That, together with what it was mentioned about the SmartTV Alliance using
it, means th
Hi Maciej,
[.]
> I think the main problem with this change is that the
> current WebCore/accessibility code has lots of knowledge
> of the DOM and render tree. Making WebCore/platform
> depend on these Web-specific concepts is a layering
> violation - imagine how it would work if it was a
> top-le
Hi Darin,
> -Original Message-
> [...]
> This is a bad idea. The platform directory has never been intended as
> the single place for all platform-specific code. It's the place for
> platform abstractions that let us cut down on platform-specific code
> elsewhere. It's not a good idea to t
Hi all,
Following the discussion in the contributors meeting about layering violations
I was thinking about moving all the accessibility stuff inside
WebCore/accessibility into a new WebCore/platform/accessibility directory.
My reasoning behind this could be summarized as this:
* Accessibility
Hi Geoff,
First of all, let me say upfront that I see all the potential advantages of
sticking to just one JS engine, and also perfectly understand the points
that most of the people here have made on favour of not supporting multiple
engines.
Also, my mail was not really a formal request to keep
Hi,
> On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen
wrote:
> [...]
> #if USE(V8)
> #if !USE(JSC)
Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
only ones doing it, so it would be great to keep those guards there.
> Geoff posted the list in part because
[Replying both Carlos and Sam's mail at once]
Hi,
> El lun, 21-01-2013 a las 17:57 -0800, Sam Weinig escribió:
> > Hi Mario,
> >
> > The motivation of the change was to reduce the chatter between the
> > WebProcess and UIProcess and reduce the amount of knowledge the
> > UIProcess has about the i
Hi,
So it seems WebKit2GTK+ builds are broken since yesterday due to this commit
(as it was already predicted by EWS in [1]):
http://trac.webkit.org/changeset/140285
... and it seems to me it's not something easily fixable since it will
certainly require a certain amount of work (and maybe a ce
Hi there,
On Tue, 2012-11-20 at 18:53 +0100, Mateusz Leszko wrote:
> Hello folks.
>
> I was wondering why all accessibility roles in webkit are named
> ‘AXRoles’ and why it is always expected to return role name with ‘AX’
> prefix? Isn’t it strict MAC role naming? Some Layout Test for
> accessibi
Hi,
I've recently started to look at a11y issues in WebKitGtk (nothing too
impressive, just taking a look by the moment :-)), and I found the
implementation a bit strange, and not sure whethers there's a reason for
that I'm missing (most likely, I'd say):
// WebKitTools/DumpRenderTree/gtk/Access
Hi,
As the result of working in bug 25524 (see [1] for more details), we
have reached the conclusion (and not only to fix that bug) that perhaps
it would be good to change how the 'alt' attribute is exposed to ATs,
switching from being the accessible description to be the accessible
name. This wou
22 matches
Mail list logo
