@kochi: gentle ping, can you please check and update, issue is tagged with a stable blocker and M63 is set to be pushed to Stable soon.

Thanks.!

Hmm, the CL is a cherry-pick merge to stable branch from ToT,
the original author is Ajith.

I don't think it makes much sense to have automated perf test against
this - removing the releaseblock label.

As we introduced a hard limit (50) to avoid the performance issue,
but it is somewhat arbitrary number.
Ajith, I think there are N^2 bug or something that the wait time is
exponential than linear, which we haven't identified yet.
Could you take time on investigating which code path gets slow when the
node size gets bigger?

As ReleaseBlock-Stable was removed, let's repurpose this issue.

@kochi - I will look into it from 04/12/2017 and update you the findings. Currently I have 2 thoughts;
1) Execute the required blink operation on a separate thread on render process.
2) Identify the performance bottle neck on the FocusController function.

@Kochi - I could see a O(n2) kind of looping in  FindFocusableElementRecursivelyForward method when we call FindFocusableElement() from current for loop.

We can avoid this, focus finding logic if we know the form elements associated with this current form in advance and just navigate through it instead of navigating more tree elements, which is outside scope of this form.

I tried to walk through the elements of the form instead of full focus search, so I am using elements() API of HTMLFormElement. But a strange problem I am observing is when there is an input element with "form" attribute outside of the form is not treating as its child, whereas if I add a textarea both input and textarea is coming as child. Still checking it.

Ajith, thanks for the update!

Currently, solution in hand is use elements() API and get prev/next element, which is kind of straight fix.

Other option is to avoid the overhead of synchronised call by using parallel execution using a thread as stated in #4 (1) approach. In this no blink side change is needed, instead push the RenderWidget call on a Thread and get the response asynchronously.

@Kochi - Could you pls share your opinion before I choose a path.

I vaguely remember I talked with tkent@ that we cannot use elements()
for Smart Go because not only form-participating elements but also
elements with tabindex has to be considered for next/prev navigation.

I don't think the threading approach work, as the current Blink DOM
assumes DOM manipulation is done in a single thread, and even just for
multiple readers, if it is on-going, we need RW lock or something that
DOM mutation should be blocked until all readers finish, but we don't have
such thing in our Blink infrastructure.
You may think reading is thread-safe, but in case some mutation happens,
it can easily touch stale pointer from reading while writer is doing
some pointer manipulation.

 Issue 802029  has been merged into this issue.

Ajith, any updates on this?

kochi@ - I just deviated from this due to some priority assignments. I will resume  it from Monday again and will update you my findings. Thank you

Thanks for the update!

kochi@ - I can see FindFocusableElementAcrossFocusScopesForward() is again traversing over a while loop from FocusController, which is the destine function call from NextFocusableElementInForm()-> for loop, which clearly a O(n^2) case.

kochi@ - Related to #10 - You mean from elements(), we need to filter again the based on tab index, rather than blindly traverse over that list while finding next element ?

kochi@ - I just looked bit more, and found 
  // Pre-order traversal skipping non-element nodes.
  static ElementType* Next(const ContainerNode& current) {} kind of saving O(n^2) problem. But I feel, the tab index will be still an issue.
If you have any other suggestion or wanted to write a new API in FocusController for our custom usage, please let me know

One other option which I could think of is from elements() list, we shall traverse by giving respect to tab index value and find the focusable elements. I am not sure any ready made API is available for this at the moment.

Keeping the current form owner as parent and scope, won't work out as we observed  elements can be linked to form from outside using form attribute.

kochi@ - Looks like as long we use FindFocusableElement() within the loop, we can't escape from this performance issue. Additionally, for preserving tab index, we don't have any other ready made API available. Right now, I have following thoughts in mind.

1) Write a parallel API for taking care of traversing only <input>/<textarea>/contenteditable elements by giving respect to tabindex.
2) Write an API for identifying next/previous when we give input a collection of elements. (Input to this function would be elements() output)

So could you please share your thoughts on how we can tackle this issue.

Hi, sorry not responding on this timely.

As I wrote in comment 10, I don't think any "parallel API" kind of thing
in Blink's DOM code is feasible.

Can we take any approach that saving search state (such as linked list of
next/prev elements) once search is done, and use the state next time unless
any DOM mutation is done?

kochi@ - Thank you for the suggestions. Let me think of this angle by referring current implementation function and get back to you.

Ping - any progress on this issue?

Downgrading to P2 since it's been open for so long.

bokan@ - I am currently engaged with another CL, after that I will resume this task. Thank you