Re: [webkit-dev] Webkit.org server maintenance - 5-7pm PDT, Thu Sep 7, 2017

[Ling Ho]

We have completed server maintenance works. Please email 
ad...@webkit.org if you encounter any problem.


Thanks.

Ling Ho
WebKit Operations



On 9/6/17 12:55 PM, Ling Ho wrote:


Webkit.org server maintenance

5-7pm PDT, Thursday,  Sep 7, 2017


We will be performing Security and OS updates on webkit.org servers 
during the maintenance period.


Some of the servers will be rebooted during the process, and service 
interruption is expected.


The following are the affected webkit.org hosts:

www.webkit.org (webkit.org)
trac.webkit.org
build.webkit.org
nightly.webkit.org
perf.webkit.org
planet.webkit.org
bugs.webkit.org
svn.webkit.org
git.webkit.org

Please email ad...@webkit.org if you have any question regarding the 
system maintenance.



Thanks,

Ling Ho
WebKit Operations



___
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] Improve selection with floats

[Javier Fernandez]

Hi,

I've been working lately on some cases where selection shows an
unpredictable behavior when applied to cases with float elements;
basically, selection boundaries jump when dragging over floats. I've
found this old bug (https://webkit.org/b/101771) which described some of
these cases. I've attached another case with the same problem.

This weird Selection's behavior is also present in Blink and Gecko:
  - https://crbug.com/758526
  - https://bugzilla.mozilla.org/show_bug.cgi?id=1397514

I'm aware of the issues we have with Selection when the Render Tree
differs from the DOM Tree's structure, but that's not the case of the
examples I've been evaluating so far; I think for these cases we can do
better.

My theory is that the root cause of this issue in most, if not all, the
cases is that we are not considering floats as valid HitTest candidates.
Additionally, we exclude floats from the positionForPoint logic,
implemented in the different render objects.

I'm evaluating a preliminary approach based on considering floats as
valid HitTest candidates. I started to address a very specific case in
https://webkit.org/b/176096 and, if it gets enough support, I have plans
to continue addressing as many cases as possible.

I think we have to assume that we will have issues with floats when they
create complex render trees, like it happens with other layout models,
but at least we can improve the simplest cases.

I appreciate any feedback on my current approach and reviews of my
patches, if we finally want to give this proposal a shot.



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

Re: [webkit-dev] Generation of documentation describing HTML5 support

[Konstantin Tokarev]

07.09.2017, 13:03, "Romain Bellessort" :
> Hi all,
>
> Safari has some documentation describing support for HTML/CSS/JS (see e.g. 
> [1]). Creating and maintaining such documentation likely requires a 
> significant amount of work.
>
> I don't know to what extent Apple folks may be able to share information 
> about this, but how much of this process is automated? (e.g. are there tools 
> that analyze parts of WebKit code to detect supported tags / attributes / 
> etc.?)
> More generally, has some work been done in this field? (for WebKitGTK for 
> instance)

https://webkit.org/status/ is automatically generated from features.json files. 
It has references to respective W3C standards/drafts.

>
> Thanks,
> Romain.
>
> [1] 
> https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariHTMLRef/Introduction.html
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Generation of documentation describing HTML5 support

[Michael Catanzaro]

On Thu, Sep 7, 2017 at 5:02 AM, Romain Bellessort 
 wrote:
More generally, has some work been done in this field? (for WebKitGTK 
for instance)


We only document our C APIs. For web documentation I look at 
developer.mozilla.org and see what it has to say about WebKit. ;)


Michael

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

[webkit-dev] Generation of documentation describing HTML5 support

[Romain Bellessort]

Hi all,

Safari has some documentation describing support for HTML/CSS/JS (see e.g.
[1]). Creating and maintaining such documentation likely requires a
significant amount of work.

I don't know to what extent Apple folks may be able to share information
about this, but how much of this process is automated? (e.g. are there
tools that analyze parts of WebKit code to detect supported tags /
attributes / etc.?)
More generally, has some work been done in this field? (for WebKitGTK for
instance)

Thanks,
Romain.

[1]
https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariHTMLRef/Introduction.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Yusuke SUZUKI]

On Wed, Sep 6, 2017 at 3:24 AM, Filip Pizlo  wrote:

>
>
> > On Sep 5, 2017, at 10:51 AM, Olmstead, Don 
> wrote:
> >
> > We have plans to add a JSC-Only windows bot in the very near future.
> Would that have any bearing on the state of JIT in Windows?
>
> Not really.
>
> Because of the poor state of that code, I think we should rip it out.
>
> Also maintaining the 32_64 value representation is no value for us.
>

I think keeping Windows support would be good. I believe Sony folks are
working on Windows improvement, and it would be fine if they can keep
watching JSC on Windows.
And it means that we can keep WebKit fast at major latest architectures
including macOS / Linux / Windows (with 64bit CPUs), which is fine.

My largest concern about dropping JIT for various platforms is that LLInt
performance would be not good compared to JIT-ed environment.
We could remove DFG for 32bit (not sure). But I think PolyIC can be
critical for performance.
JS performance largely depends on this feature.

BTW, I strongly agree that newer feature should focus on 64bit
architecture. (I'm opposed to adding 32bit support to FTL).



>
> -Filip
>
>
> >
> > -Original Message-
> > From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf
> Of Filip Pizlo
> > Sent: Tuesday, September 5, 2017 8:37 AM
> > To: Adrian Perez de Castro 
> > Cc: webkit-dev@lists.webkit.org
> > Subject: Re: [webkit-dev] Bring back ARMv6 support to JSC
> >
> > There isn’t anyone maintaining the 32-not JIT ports to the level of
> quality we have in our 64-not ports. Making 32-bit use the 64-bit cloop
> would be a quality progression for actual users of 32-bit.
> >
> > -Filip
> >
> >>> On Sep 5, 2017, at 8:02 AM, Adrian Perez de Castro 
> wrote:
> >>>
> >>> On Tue, 5 Sep 2017 16:38:09 +0200, Osztrogonác Csaba <
> o...@inf.u-szeged.hu> wrote:
> >>>
> >>> [...]
> >>>
> >>> Maybe it will be hard to say good bye to 32-bit architecutres for
> >>> many people, but please, it's 2017 now, the first ARMv8 SoC is out 4
> >>> years ago, the first AMD64 CPU is out 14 years ago.
> >>
> >> While it's true that amd64/x86_64 has been around long enough to not
> >> have to care (much) about its 32-bit counterpart; the same cannot be
> said about ARM.
> >> It would be great to be able to say that 32-bit ARM is well dead, but
> >> we are not there yet.
> >>
> >> If we take x86_64 as an example, it has been “only” 10 years since the
> >> last new 32-bit CPU was announced and until 3-4 years ago it wasn't
> >> uncommon to see plently of people running 32-bit userlands. If things
> >> unroll in a similar way in the ARM arena, I would expect good 32-bit
> >> ARM support being relevant at least for another 3-4 years before the
> need starts to fade away.
> >>
> >> If something, I think it may make more sense to remove 32-bit x86
> >> support, and have the 32-bit ARM support around for some more time.
> >>
> >> Cheers,
> >>
> >>
> >> --
> >> Adrián 
> >>
> >> ___
> >> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev