Re: [webkit-dev] webkit-patch land behavior change

[Manuel Rego Casasnovas via webkit-dev]

On 26/04/2022 21:58, Jonathan Bedard via webkit-dev wrote:
> As we move closer to transitioning away from Subversion, I’ve change 
> ‘webkit-patch land’ to use commit-queue instead of directly committing a 
> local change from a contributor’s machine 
> (https://github.com/WebKit/WebKit/pull/392). ‘git-webkit land-unsafe’ will 
> allow contributors to directly land to Subversion for the time being, 
> although after we transition to GitHub, will also use commit-queue and prefix 
> “fast-cq” to uploaded patches to bypass building and testing.

If I remember correctly when you're accepted as committer you have to do
a first manual commit adding you to the contributors.json file; and I
guess people are using "webkit-patch land" for that (see example [1]).

Would the new contributors be able to land that first commit with the
commit-queue behavior?

Cheers,
  Rego

[1] https://bugs.webkit.org/show_bug.cgi?id=237634
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS queue: Stress Test EWS

[Manuel Rego Casasnovas via webkit-dev]

Hi,

The stress test EWS has some issue when dealing with testharness.js tests.

Every now and then it thinks it's a different type of test and it dumps
the layout tree, and it fails as the actual result has nothing to do
with a layout tree dump.

Actually it dumps an empty layout tree:
 layer at (0,0) size 800x600
   RenderView at (0,0) size 800x600
 layer at (0,0) size 800x600
   RenderBlock {HTML} at (0,0) size 800x600
 RenderBody {BODY} at (8,8) size 784x584

Last example I've seen:
https://ews-build.webkit.org/#/builders/62/builds/1903

I guess there might be some timing issue or something like that, as it
looks like it doesn't even load the test properly before comparing the
results.

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

Re: [webkit-dev] WebKit Transition to Git

[Manuel Rego Casasnovas]

On 14/10/2020 03:12, Ken Russell wrote:
> On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev  > wrote:
> 1. Workflow 1 - "Squash merge" policy
> 
> * Whole PR is considered to be a single atomic change of WebKit
> source tree. If work is supposed to be landed as a series of changes
> which depend on each other (e.g. refactoring and feature based on
> it, or individual separate features touching same parts of code),
> each change needs a separate PR, and, as a consequence, only one of
> them can be efficiently reviewed at the moment of time
> * Commits in PR represent review iterations or intermediate
> implementation progress
> * Reviewers' comments are addressed by pushing new commits without
> rewriting history, which works around GitHub's lack of "commit
> revisions". Also this workflow has lower entry barrier for people
> who haven't mastered git yet, as it requires only "git commit" and
> "git push" without rebases.
> 
> 2. Workflow 2 - "Rebase" ("cherry-pick")) or "Merge" policy
> 
> * PR is considered to be a series of atomic changes. If work
> consists of several atomic changes, each commit represent an atomic
> change
> * Review iterations are done by fixing commits in place and
> reuploading entire series using force push (of course if review
> discovers that substantial part of work is missing it can be added
> as a new atomic commit to the series)
> * It's possible to review each commit in the series separately
> * Workflow requires developers to have more discipline and
> experience with using git rebase for history rewriting. Entry
> barrier can be lowered by providing step by step instructions like
> e.g. [1].
> 
> 
> Workflow 1 is more like what we have now with Bugzilla.
> 
> Workflow 2 is used by many projects which use git for a long time
> and value high-quality commit history. It's used e.g. by Linux
> kernel, or projects which use Gerrit as a review tool (Chromium,
> Android, Qt, etc). It advantages for developers (who can submit more
> work to review at the same time without risk of mixing up unrelated
> changes together), reviewers (it's easier to review atomic changes
> than those with too high or too low granularity), maintainers of
> stable branches (they can pick bug reports and avoid at least some
> unneeded refactorings, features and style improvements).
> 
> 
> Slight correction: Chromium's Gerrit instance actually uses Workflow 1 -
> the "squash merge" policy. The developer can have multiple Git commits
> on a single branch and associated with a single Gerrit code review. Each
> time the branch is uploaded into the review tool, all of those commits'
> diffs are squashed together into the current patchset - the new version
> of the review.

Yeah this Workflow 1 has been working fine in Chromium since the fork,
and it's pretty similar to what we currently have in WebKit bugzila, so
I think it'd be the best option when WebKit is on Git too.

If I understood correctly, the only difference with Chromium's Gerrit
would be that you cannot mark dependencies between PRs, but that's not
something that people use every day (mostly is used when you want to
test your patches in advance against the tryjobs/EWS or the perfbots)
and as Ryosuke mentioned you could share that WIP commits in your own
branch, or even in a dummy PR if you need to check EWS results and
discard that afterwards once it's split in several PRs.

I also don't see the problem with creating a new bug entry for a small
change and make the change separately, I have asked for that kind of
things in WebKit bugzilla a few times when I reviewed a patch that had
some unrelated change that could be landed separately. I know that's not
always the case and sometimes we land bigger patches than it should, but
I think that's more on the author and reviewer considerations.

My 2 cents,
  Rego
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Experimental and (new) Internal feature flags

[Manuel Rego Casasnovas]

On 25/09/18 01:00, Ryosuke Niwa wrote:
> On Mon, Sep 24, 2018 at 1:26 AM Frédéric Wang  > wrote:
> 
> On 12/09/2018 23:48, Dean Jackson wrote:
> > What about testing?
> > 
> >
> > You can turn both experimental and internal features on via
> headers in WebKitTestRunner. Use experimental:FeatureName or
> internal:FeatureName. For example...
> >
> > 
> IIUC some platforms (WK1?) still use DumpRenderTree to run tests? Are
> such headers taken into account on these platforms too?
> 
> 
> Both DRT & WTR parses webkit-test-runner flags just like "testRunner"
> object in DRT & WTR implements the same API.

I'm not sure about DRT. It seems you need to modify
https://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/TestOptions.cpp#L102
in order that these headers work there.

My 2 cents,
  Rego
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] A couple more build flags to review

[Manuel Rego Casasnovas]

On 20/02/18 20:09, Michael Catanzaro wrote:
> ENABLE_CSS3_TEXT looks to be support for text-align-last and
> text-justify [1]. Seems to be only partically implemented in WebKit. I
> guess this is the sort of thing that should probably be implemented
> eventually, so probably makes sense to keep it around and disabled for now.

I'm not sure about this. As you said ENABLE_CSS3_TEXT
is not being enabled by any port, this means that the tests
are not being run and that the related code is not being tested.

ENABLE_CSS3_TEXT flag seems to be used only for:
* -webkit-text-align-last property
* -webkit-text-justify property
* -webkit-each-line & -webkit-hanging keywords of text-indent

I don't know if anyone has plans to work on this stuff,
but if you enable now the flag, only the parsing tests are passing
the ones checking the behavior are broken.
I see that the last patches around these things are from 2014.

Actually we were enabling this flag in development builds in GTK+
for a while, and we got some regressions in these tests
due to some other changes (see bugs #163980 and bug #163982).
That was in 2016 so some stuff seems to have been broken since then.

I guess that if nobody has plans to work on this, update them
(to avoid prefixes) and make them work properly; the next step
should be removing the compilation flag together with
the associated code and tests.
If someone eventually wants to implement it, they could start over
or use the old code, but keeping untested code in the tree
without a clear plan doesn't seem like a great idea to me.

My 2 cents,
  Rego
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename LayoutTests

[Manuel Rego Casasnovas]

On 10/05/17 04:23, Ryosuke Niwa wrote:
> Continuing the tradition of a massive rename in
> https://lists.webkit.org/pipermail/webkit-dev/2012-August/021746.html,
> I suggest we rename the top-level LayoutTests directory to something
> more descriptive of the current state.
> 
> Some ideas:
> IntegrationTests - Represents what they are for WebCore.
> AutomatedTests - As opposed to ManualTests.
> ContentTests - Not great for tab completion.
> WebTests - Probably a bad idea for tab completion.

The very same discussion is happening right now on blink-dev:
https://groups.google.com/a/chromium.org/d/topic/blink-dev/KKNbuzj-3HY/discussion

A document with some ideas and pros/cons of each one:
https://docs.google.com/document/d/1wLSfod8apDy2sZsmXpTLRacfjweXP86C-V0wx5koJBg/edit

BTW, on a first sight I like "WebTests/" or even "Tests/".

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

Re: [webkit-dev] WebKit servers transitioning to new hardware

[Manuel Rego Casasnovas]

Hi,

Dunno if it was related to this or something else but planet.webkit.org
is not being updated since March 10, 2017.

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

Re: [webkit-dev] Unprefixing intrinsic size keywords (-webkit-min-content et al)

[Manuel Rego Casasnovas]

On 08/08/15 00:22, Dean Jackson wrote:
> 
>> On 7 Aug 2015, at 2:44 AM, Christian Biesinger  
>> wrote:
>>
>> Hi all!
>>
>> We (blink) would like to unprefix the intrinsic sizing keywords:
>> https://drafts.csswg.org/css-sizing/#width-height-keywords
>>
>> We support them for widths and for heights (though they all do the
>> same thing for heights)
>>
>> We were wondering what Webkit's plan for those keywords is -- are you
>> also interested in unprefixing? Are you happy with the keywords as
>> specced? Would you rather stop supporting them?
> 
> Is there a test suite?
> 
> I think WebKit should unprefix these keywords.

Some time has passed, but I've worked on patch to unprefix min-content,
max-content and fit-content (the same that was done by Christian in Blink).
You can find it at:
https://bugs.webkit.org/show_bug.cgi?id=169195

This is really useful now that we're shipping CSS Grid Layout, as right
now we've everything unprefixed for Grid Layout but min-content and
max-content. So for example you have to write:
  grid-template-columns: -webkit-min-content fit-content(500px)
 -webkit-max-content;
Instead of:
  grid-template-columns: min-content fit-content(500px) max-content;

That combination of prefixes (min-content and max-content) vs non
prefixes (fit-content()) is really strange.

You can find more details on the bug report.

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

Re: [webkit-dev] On/Off selection gap painting during the text selection

[Manuel Rego Casasnovas]

On 03/05/16 17:12, Gyuyoung Kim wrote:
> In second issue case, although it looks there is no critical issue with
> new layout methods yet
> I think I need to check it further. But the issues won't appear on port
> which uses gaps painting.

Maybe I didn't explain myself properly, but the issue with new layout
methods is happening when you paint the selection gaps, if you don't
paint them the issue disappears.

A very simple example with Flexbox:

  first
  second
  third
  fourth


Try to select from "first" to "third", with selection gaps painting the
final result is really bad. Without gaps painting it should be better.
You can check it live here: http://jsbin.com/getafojevu/1/edit

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

Re: [webkit-dev] On/Off selection gap painting during the text selection

[Manuel Rego Casasnovas]

Hi,

On 03/05/16 15:24, Gyuyoung Kim wrote:
> I upload a patch to add a preference API in order to enable/disable the
> selection gap painting feature.

BTW, this has been removed from Chrome too past year:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/6Iu5oIbAGbI/PsJlNvJPhfMJ

Note that in the discussion they pointed to an issue that happens when
you remove gaps paining, you don't know if you've selected a newlines or
not: https://bugs.chromium.org/p/chromium/issues/detail?id=474759

> Add WKPreference for SelectionPaintingWithoutSelectionGaps
> https://bugs.webkit.org/show_bug.cgi?id=156900

As pointed out by Darin on the bug, an issue with selection gaps is what
happens with the new layout methods like Flexbox and specially Grid
Layout, where the visual order and the DOM order can be completely
different.

My 2 cents,
  Rego
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] About unprefixing CSS Grid Layout (implementation status summary included)

[Manuel Rego Casasnovas]

On 30/04/16 00:17, Dean Jackson wrote:
> Please leave the build flag around. We probably need a bigger discussion
> on this, but for now we should have both a runtime flag and a build flag
> just in case a browser ships and doesn't want the feature compiled at all
> (reducing binary size).

Ok, no problem from our side, we'll have both the build flag and the
runtime flag together. Eventually once we ship Grid Layout, we'll get
rid of both.

BTW, the runtime flag has already landed (r200215) and the unprefixing
patch is ready for review: http://webkit.org/b/157137

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

[webkit-dev] About unprefixing CSS Grid Layout (implementation status summary included)

[Manuel Rego Casasnovas]

Hi,

as announced yesterday it seems that the WebKit prefixing policy has
been updated [1].

Right now CSS Grid Layout implementation is prefixed in WebKit and
behind a compilation flag.
We'd like to ask about the possibility to unprefix it and put it behind
a runtime flag (probably removing the compilation flag too).

The thing is that current implementation is almost the same than then
one in Chromium, which is also very similar to the support in Firefox.
In both Chromium and Firefox Grid Layout is unprefixed and behind a
runtime flag.
If we unprefix Grid Layout in WebKit too, it'd have a bunch of benefits:
* Easier to test for web authors (they don't need to add prefixes so
they don't get confused if they try examples from the spec directly and
they don't work).
* Easier to use Chromium and Firefox tests in WebKit to check
interoperability.
* Easier to run the W3C test suite (which is not complete yet) without
having to deal with the prefixes stuff.

We believe that it'd be a nice thing to do, and it'll put Safari in the
same position than other browsers that are implementing the spec.

Regarding to the status of our implementation, it's been a while since
we don't send a summary to this list (sorry about that).
Anyway my mate Javi Fernández was talking about it in the WebKit
Contributors Meeting 1 year ago [2].
In addition, we've been writing blog posts that appear in the planet
explaining the main features we've been developing.

The main tasks performed since past year were:
* Auto-placement algorithm has been complete. [3]
* Implemented spec section about implied minimum size of the grid items.
* Full support for absolute positioned items (missing alignment support).
* Progress on orthogonal flows support in the track sizing algorithm.
* Almost finished implementation of Box Alignment spec (missing baseline
alignment and some updates to the last changes in the spec). [4]
* Update track sizing algorithm due to the changes in the spec during 2015.
* Syntax changes from the spec (shorthands, gutters, etc.).
* Placement refactoring to support implicit grid before explicit grid. [5]
* Some investigation and measurements regarding performance on grids,
optimizations to be done once the implementation stabilizes. [6]
* Contribute some tests to the W3C Test Suite [7].
* Starting to support auto-repeat features.

This year we've been doing a great effort to move WebKit implementation
closer to the one in Blink. Right now most of the patches have been
ported from Blink or are on the way. We're currently working in some of
the last missing features from the spec, and we keep updating the
implementation to the changes introduced on it.

The CSS Working Group is discussing right now about the possibility to
simplify subgrids or defer it to Level 2 definitively [8]. Depending on
that decision we'll have more or less work pending to do before being
able to ship this feature.
BTW, editors are planning to move the specification to Candidate
Recommendation soon.
Also, web authors seem really excited about the possibility to use Grid
Layout for their designs.

Bye,
  Rego

[1] https://webkit.org/blog/6131/updating-our-prefixing-policy/
[2] https://trac.webkit.org/wiki/March%202015%20Meeting
[3] http://blogs.igalia.com/mrego/2015/02/25/grid-auto-placement-is-ready/
[4] http://blogs.igalia.com/jfernandez/distributing-tracks-along-grid
and http://blogs.igalia.com/jfernandez/box-alignment-and-grid-layout-ii
[5]
http://blogs.igalia.com/mrego/2016/02/01/deep-dive-into-grid-layout-placement/
[6]
http://blogs.igalia.com/jfernandez/2015/06/24/performance-on-grid-layout/
[7] https://github.com/w3c/csswg-test/tree/master/css-grid-1
[8] https://lists.w3.org/Archives/Public/www-style/2016Apr/0254.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] CSS Grid Layout Status Review (Jan 2015)

[Manuel Rego Casasnovas]

Hi,

this is a new status review (last one was in August 2014 [1]) of the CSS
Grid Layout [2] implementation done by Igalia. We'll summarize the work
done during the past months and the plans for the future.
Of course, we'll be really happy to get any kind of feedback from the
community.

The meta-bug to follow the evolution of this feature is:
http://wkb.ug/60731


Main tasks done since August:

* Track Sizing Algorithm (http://wkb.ug/60731):
  * Tracks no longer shrink with undefined remaining space.
  * Fixed the grow beyond growth limits use case.
  * Do not use items spanning through flex tracks when sizing content
sized tracks.
  * Sizing content sized tracks is no longer order-dependent.
  * Support of percentages of indefinite sizes in minmax().

* Auto-placement (http://wkb.ug/103316):
  * Support sparse & dense packing modes.
  * Stack mode was finally dropped from the spec.

* Alignment & justification (http://wkb.ug/133224 & http://wkb.ug/133222):
  * Upgrade self alignment properties (justify-self/items,
align-self/items) to the last CSS3 spec.

* Testing:
  * Improve test coverage, which lead to some bug reports and fixes.
  * Outside WebKit: Started to create the W3C test suite for grid [3].
Still on early stages, check the test plan [4] for more information.

* Bugfixing:
  * Fixed different bugs reported by fuzzinator.
  * Generic bugfixing.


Ongoing tasks:

* Track Sizing Algorithm (http://wkb.ug/60731):
  * Initialization of track sizes from non spanning items.
  * Add and enforce the growth limit >= base size constraint.
  * Improve sizing computations of tracks growing beyond limits.
  * Fix behavior under min/max-width and min/max-content.
  * Add support for mark as infinitely growable and unmark.
  * Rewrite some of the loops that are incorrectly nested.

* Alignment & justification (http://wkb.ug/133224 and http://wkb.ug/133222):
  * Due to some performance concerns, CSS3 upgrade of alignment
properties is stalled.
  * There're several patches pending to fully support the Box Alignment
specification in WebKit.

* Testing:
  * Outside WebKit: Continue working on the W3C test suite in order to
cover the whole spec. Then, import the test suite into WebKit.


Plans for the future:

* Absolutely positioned grid children.

* Alignment & justification
  * Implementation of the Box Alignment spec for Grid Layout.
  * Dealing with orthogonal flows.

* Writing modes.
  * Adapting the track sizing and item positioning to any writing mode
and direction.
  * Implementing support for orthogonal flows.
  * Handling grid's and item's margin, border and padding in different
writing modes and directions.

* Support "auto" keyword for repeat() function.

* Allow to grow the implicit grid before the explicit grid (supporting
properly negative indexes for grid line numbers).

* Implement fragmentation support once the spec is definitive regarding
this topic.

* Performance analysis and optimizations.

* Grid support on Web Inspector.


This is a high level summary, you can check the different bugs for more
details. Please don't hesitate to ask any question. We hope you find
this information useful.

BTW, you can already test CSS Grid Layout using the WebKit nightly
builds (remember to use "-webkit" prefix) [5].

Best regards,
  Rego

[1] https://lists.webkit.org/pipermail/webkit-dev/2014-August/026756.html
[2] http://dev.w3.org/csswg/css-grid/
[3] http://test.csswg.org/shepherd/search/spec/css-grid-1/
[4] http://rawgit.com/w3c/csswg-test/master/css-grid-1/test-plan/index.html
[5] http://nightly.webkit.org/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Manuel Rego Casasnovas]

Hi,

On 11/07/14 22:38, Joseph Pecoraro wrote:
>   - GTK EWS bot has "Unable to build without patch” with:
>   ninja: error: build.ninja:3225: lexing error

We found the problem and the EWS should be running properly again.

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

I don't know about any list, but usually you can contact me or
lti...@igalia.com for any issue with the EWS GTK+ bots (other people in
Igalia could be an option too if we're not around).

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

Re: [webkit-dev] Enabling CSS Grid Layout runtime flag by default

[Manuel Rego Casasnovas]

On 25/04/14 23:39, Benjamin Poulain wrote:
> On 4/25/14, 5:21 AM, Javier Fernandez wrote:
>> If everybody agrees, we have a patch ready to do this change:
>> http://webkit.org/b/132189

JFYI, we've just landed this change today (r167993).

> Personally, I think you should remove the runtime flag, and be very
> aggressive on the #ifdefs to make sure everything can be disabled when
> shipping.

Good idea, so this would be the next step. We're already spotting some
missing places where we should use the ENABLE_CSS_GRID_LAYOUT
compilation flag. Then we'll provide a patch to remove the runtime feature.

> It would be nice if you could email webkit-dev from time to time about
> your progress on completeness, testing, performance, etc.

Yeah, we should do it. We'll try to collect all the information and
share it with you in the coming weeks.

Thanks for the feedback,
  Rego

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

Re: [webkit-dev] On web-exposing features disabled at runtime

[Manuel Rego Casasnovas]

On Mon, 2014-02-10 at 13:38 -0800, Benjamin Poulain wrote:
> Can't we add a compile time flag instead?
> The chromium patch you linked is inelegant and it touches some hot paths.

BTW, only with the compile flag the issue is not completely fixed.

For example you can enable the compile flag but disable the feature at
runtime and the properties will be exposed anyway.

IMHO, if the feature is disabled at runtime the properties shouldn't be
exposed.

My 2 cents,
  Rego

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

Re: [webkit-dev] [blink-dev] Selection & CSS Regions

[Manuel Rego Casasnovas]

Hi Yosi,

On 20/12/13 02:37, Yoshifumi Inoue wrote:> I would like to provide
render tree iterator base rendered position from
> Render Tree for TextIterator, Selection, and others. TextIterator is the
> first client of its.

Ok, I guess that it could be something similar to the RenderIterator
that has been recently introduced in WebKit:
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderIterator.h

> I'm not clear about traversing doesn't solve CSS region selection. Does
> it come from current implementation? Or, is traversing wrong idea?

What I mean is that regular traverse of the render tree won't fix
selection issues in CSS Regoins (neither in absolute positions for
example).

Let me explain with a simple example:
http://people.igalia.com/mrego/css/regions/example.html

The Render tree is something like:
RenderView
  RenderHTML
RenderBody
  RenderBlock content-1
  RenderRegion region-1
  RenderBlock content-2
  RenderFlowThread
RenderBlock source-1

However visually you get something like:
content-1
region-1
  source-1
content-2

If you select from "content-1" to "content-2" and you traverse render
tree, you won't process "source-1".

So, we'd need some special conditions for CSS Regions in the
RenderIterator, to jump to the RenderFlowThread subtree (and the other
way around) when needed. I guess this is ok, as it's an implementation
detail.

> BTW, changing selection will be after TextIterator, because  exposing
> selected node to JavaScript needs new API, e.g.
> Selection.getNodeSet(scope). So, it will come later.

I agree that this will be after TextIterator, just trying to understand
the whole picture.

About changing the selection I'm thinking in RenderView::setSelection()
method. This method should also use the RenderIterator instead of
regular render tree traversing to fix the problem.

BTW, where can I find information about that new API
"Selection.getNodeSet(scope)"? It is not in the editing spec [1].

Thanks,
   Rego

[1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selection

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

Re: [webkit-dev] [blink-dev] Selection & CSS Regions

[Manuel Rego Casasnovas]

Hi Yosi,

On 19/12/13 02:17, Yoshifumi Inoue wrote:
> Selection for Shadow DOM tree is similar to CSS Region. Shadow DOM tree
> also randomizes rendering order against (shadow/non-shadow) DOM tree order.
> 
> Using render tree information for selection also allows us to handle
> position:absolute elements, e.g. advertised elements displayed displayed
> at page bottom.
> 
> We have a plan to make TextIterator to traverse Render Tree rather than
> DOM tree for ease and robust support of Shadow DOM tree.

Let me check if I understand your mail properly.

You're talking about fixing the selection from the user point of view
forgetting about selection being always DOM based (like in editing
spec).

For example in the following page with absolute positions, the idea
would be that when you select from content-1 to content-2, absolute-1
text is not selected:
http://people.igalia.com/mrego/css/absolute/example.html

I agree that this would be the best solution from the user point of
view.

So, if I'm not wrong, the plan is to make TextIterator traverse the
render tree, so things like shadow DOM, absolute positions or CSS
Regions could be properly traversed.

I'm wondering if the next step would be that selection's algorithms
use TextIterator to traverse the render tree too or not. If not I
guess that similar changes should be needed in rendering code.

As a side note, in CSS Regions it might be needed to jump from a
RenderRegion to its content in the RenderFlowThread and the other way
around. That could be done in TextIterator as we'll have all render
tree information. Directly traverse of the render tree won't fix the
issue in CSS Regions.

Thanks for your feedback,
   Rego

PS: I've been testing different layout models (shadow DOM, absolute
positions, flexbox and regions) checking selection's behavior, you can
find a summary at:
https://github.com/Igalia/css-regions-selection/wiki/Selection-&-Other-layout-models

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

[webkit-dev] Selection & CSS Regions

[Manuel Rego Casasnovas]

Hi,

we've been working for a while in selection and CSS Regions.

Current implementation is working fine from the DOM tree point of view,
the retrieved content when you do a selection is right (fulfilling the
editing spec [1]).

However, in several use cases with CSS Regions, highlighted content in
the view does not match with the retrieved one, which is wrong.

We've been thinking in different 2 different approaches to fix this
problem. They're explained in detail in the following wiki page:
https://github.com/Igalia/css-regions-selection/wiki/Selection-&-CSS-Regions

Sorry for the cross posting, but we'd like to know the opinion, doubts
and concerns of editing/selection experts in both projects (WebKit and
Blink) before going further with the implementation.

What do you think? Could any of these approaches be eventually
integrated upstream?

Thank you very much,
   Rego

[1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [WIP][GTK] Memory leak detection

[Manuel Rego Casasnovas]

Hi Brian,

On 05/20/2013 04:48 PM, Brian Holt wrote:
> Memory leak detection is a recurrent topic on this mailing list [1-5]
> but at present there exists only support for the Mac leaks tool[6].  The
> de facto standard for memory checking and leak detection for Unix is
> Valgrind and the goal of this work is to launch the DRT under Valgrind
> to generate a xml file with details of leaks found, and then to parse
> this file and display this information.

My mate Edu Lima has recently added documentation about how to use
valgrind to find memory leaks in WebKitGTK+ using MiniBrowser:
https://trac.webkit.org/wiki/WebKitGTK/TrackingMemoryErrors

> This work is being tracked under
> https://bugs.webkit.org/show_bug.cgi?id=116317.
> 
> This is a work in progress, but as a first attempt leak checking can be
> done using the existing run-webkit-tests script as follows:
> 
> $ Tools/Scripts/run-webkit-tests --gtk --leak --wrapper="valgrind"
> LayoutTests/accessibility/accessibility-node-memory-management.html

It looks nice, once this is ready we should update the wiki accordingly.

My 2 cents,
   Rego
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev