Open question: Improving find-in-page tasks

[Rakina Zata Amni]

Hi all,

Currently find-in-page is done during idle time with idle tasks, and done in chunks of (layout) blocks until the idle time runs out (we've reached the IdleDeadline time), continuing the remaining blocks on the next idle period, or 100 ms later to ensure that find-in-page doesn't take too long. This approach is somewhat new (landed early 2019), previously we always do find-in-page in 100ms chunks.

With the new approach, find-in-page on large documents won't block other tasks for too long, adding matches gradually to the total match count. The downside is, on pages that are always busy/doesn't have idle time, find-in-page will take a long time. Maybe this is even more annoying when the search text has only a few matches (or even just one), because it might take a long time for the user to get something meaningful. We've also noticed an oversight: while we do have the 100ms timeouts (we will do at least one find-in-page task per 100ms), we will only do one layout block for that task because apparently we have exactly 0ms of idle time during those timeouts. So for large pages that have no idle time at all (not sure how often this is in real life, but for example the HTML Spec on a slow debug build is hitting this on my workstation), we will do just one block per 100ms.

The fix for this is technically easy: just do more than one block per 100ms - I tried changing it so that we do at least 10ms of work per 100ms, and find-in-page seems to be more usable that way. However, I'm not sure if this is the best approach? For example, fergal@ suggested 1ms of work per 10ms so that we don't block too long. Should we look at other possibilities too, such as doing once each animation frame? Should we do longer chunks or more smaller chunks? How common is it for pages that have no idle time?  Should we reconsider having higher priority for find-in-page tasks? Or wilder ideas?

I don't really know how to say whether one approach is better than the other here, so I'm wondering if there's anybody with an opinion on this or find-in-page in general on this list. If so, please let me know what you think :)

--

Regards,

Rakina

[Kentaro Hara]

My personal opinion is: use non-idle tasks with e.g., 10 ms of chunks without any delay.

When a user is using find-in-page, the user's expectation is to get the result asap. Prioritizing the find-in-page tasks makes a lot of sense to me :)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r4sBHWvEtcGcS%3D3FZt1%3DQtsNH-wZHUEs45zkdtuo%2BxDAw%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

[PhistucK]

I second your personal opinion. :) Find-in-page can be very, very frustrating (but maybe I am used to the pre-2019 experience and tried not to depend on it ever since).

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyYkTEgC3-Xr5kw8PSP6S5wOzaV4UOStd1bO4ANmS3JVg%40mail.gmail.com.

[Yoshifumi Inoue]

Scheduling of find-in-page task seems to be complex due by:

- Needs to do find-in-page, multiple documents, e.g. main document + <iframe>s (ad, SNS discussion thread, etc.)

- No idle time (we are not sure why we don't have idle-time for some pages)

- No user feedback in find-in-page progress (it may be better have progress bar or rotating ring)

- Fixed chunk time; it is better to determine chunk time by CPU speed.

- Displaying number of matches (Safari doesn't show it). This number also indicates failed match as "0/'0"

It is important that providing responsive UI. UX team may have good idea do so.

-yosi

On Wednesday, November 27, 2019 at 11:44:23 PM UTC+9, PhistucK wrote:

I second your personal opinion. :) Find-in-page can be very, very frustrating (but maybe I am used to the pre-2019 experience and tried not to depend on it ever since).

☆PhistucK

On Wed, Nov 27, 2019 at 4:25 PM Kentaro Hara <har...@chromium.org> wrote:

My personal opinion is: use non-idle tasks with e.g., 10 ms of chunks without any delay.

When a user is using find-in-page, the user's expectation is to get the result asap. Prioritizing the find-in-page tasks makes a lot of sense to me :)

On Wed, Nov 27, 2019 at 10:13 PM 'Rakina Zata Amni' via blink-dev <blin...@chromium.org> wrote:

Hi all,

Currently find-in-page is done during idle time with idle tasks, and done in chunks of (layout) blocks until the idle time runs out (we've reached the IdleDeadline time), continuing the remaining blocks on the next idle period, or 100 ms later to ensure that find-in-page doesn't take too long. This approach is somewhat new (landed early 2019), previously we always do find-in-page in 100ms chunks.

With the new approach, find-in-page on large documents won't block other tasks for too long, adding matches gradually to the total match count. The downside is, on pages that are always busy/doesn't have idle time, find-in-page will take a long time. Maybe this is even more annoying when the search text has only a few matches (or even just one), because it might take a long time for the user to get something meaningful. We've also noticed an oversight: while we do have the 100ms timeouts (we will do at least one find-in-page task per 100ms), we will only do one layout block for that task because apparently we have exactly 0ms of idle time during those timeouts. So for large pages that have no idle time at all (not sure how often this is in real life, but for example the HTML Spec on a slow debug build is hitting this on my workstation), we will do just one block per 100ms.

The fix for this is technically easy: just do more than one block per 100ms - I tried changing it so that we do at least 10ms of work per 100ms, and find-in-page seems to be more usable that way. However, I'm not sure if this is the best approach? For example, fergal@ suggested 1ms of work per 10ms so that we don't block too long. Should we look at other possibilities too, such as doing once each animation frame? Should we do longer chunks or more smaller chunks? How common is it for pages that have no idle time?  Should we reconsider having higher priority for find-in-page tasks? Or wilder ideas?

I don't really know how to say whether one approach is better than the other here, so I'm wondering if there's anybody with an opinion on this or find-in-page in general on this list. If so, please let me know what you think :)

--

Regards,

Rakina

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r4sBHWvEtcGcS%3D3FZt1%3DQtsNH-wZHUEs45zkdtuo%2BxDAw%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoshifumi Inoue]

Correction Safari displays number of matches like "2 matches" without active match and "Not found".

Safari also shows the page in little dark to indicate find-in-page mode(?).

[Alexander Timin]

Yeah, using idle time for user-visible (and arguably user-blocking) tasks sounds like something that can go terribly wrong.

My suggestion would be to do the work in ~50ms chunks with high priority but ensure that we don't starve out other tasks completely, dropping the priority to low if they start to take more than X percent of the total time. We have the infrastructure for this, so this should be easy to hook.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r4sBHWvEtcGcS%3D3FZt1%3DQtsNH-wZHUEs45zkdtuo%2BxDAw%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyYkTEgC3-Xr5kw8PSP6S5wOzaV4UOStd1bO4ANmS3JVg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38938ba9-873e-4f0d-b4ef-91e14649f64d%40chromium.org.

[Koji Ishii]

What about using blocking, non-idle task for the next match when user requested, but keep the rests in the idle task?

Pressing ctrl-G (next match) may block, but when I pressed it, I'd like to find it.

2019年11月28日(木) 14:58 Yoshifumi Inoue <yo...@chromium.org>:

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r4sBHWvEtcGcS%3D3FZt1%3DQtsNH-wZHUEs45zkdtuo%2BxDAw%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyYkTEgC3-Xr5kw8PSP6S5wOzaV4UOStd1bO4ANmS3JVg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38938ba9-873e-4f0d-b4ef-91e14649f64d%40chromium.org.

[Koji Ishii]

What about using blocking, non-idle task for the first match, or the next match when user requested, but keep the rests in the idle task?

Pressing ctrl-G (next match) will block, but when I pressed it, I'd like to find it. 

2019年11月28日(木) 14:58 Yoshifumi Inoue <yo...@chromium.org>:

Correction Safari displays number of matches like "2 matches" without active match and "Not found".

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r4sBHWvEtcGcS%3D3FZt1%3DQtsNH-wZHUEs45zkdtuo%2BxDAw%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyYkTEgC3-Xr5kw8PSP6S5wOzaV4UOStd1bO4ANmS3JVg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38938ba9-873e-4f0d-b4ef-91e14649f64d%40chromium.org.

[PhistucK]

And the result gathering process can be indicated by a small throbber next to the "#/#".

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACQRE%2BQ-rcNWo%3Dmbv%3DXRSccgrbpTrKq3p-ZbtbnUq13P_jiwzA%40mail.gmail.com.

[Rakina Zata Amni]

Hi all,

Thanks for the input and sorry for the delay in replying to this thread again!

I managed to discuss this with altimin@ from the Scheduling team, and I've summarized it to a doc. It looks like it makes sense to treat find-in-page with a high/very-high priority at least until it found a match, and with a slightly lower (but higher than best-effort/idle tasks) for counting all the matches. Alexander mentioned, there is already infrastructure to do this and the plan is to implement that for now.

I've also mentioned other ways to improve find-in-page outside of the scheduling part, if anyone is interested in implementing they are more than welcome to :)