Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: flutter-team-archive/engine
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: c50eb8a65097
Choose a base ref
...
head repository: flutter-team-archive/engine
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 015f3b1dec53
Choose a head ref
  • 2 commits
  • 4 files changed
  • 2 contributors

Commits on Sep 5, 2024

  1. Fix unexpected ViewFocus events when Text Editing utilities change fo… 

    …cus in the middle of a blur call. (#54965)

In [some cases][1], text editing utilities re-focus the `<input />` element during a blur event. This causes an unusual sequence of `focusin` and `focusout` events, leading to the engine sending unintended events.

Consider the following HTML code:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title></title>
</head>
<body>
  <div id="container">
    <input type="" value="1" id="input1">
    <input type="" value="2" id="input2">
    <input type="" value="3" id="input3">
  </div>

  <script>
    container.addEventListener('focusin', (ev) => {
      console.log('focusin: focus was gained by', ev.target);
    });
    container.addEventListener('focusout', (ev) => {
      console.log('focusout: focus is leaving', ev.target, 'and it will go to', ev.relatedTarget);
    });
  </script>
</body>
</html>
```

Clicking input1, then input2, then input3 produces the following console logs:

```
// Input1 is clicked
focusin: focus was gained by <input type value=�"1" id=�"input1">�

// Input2 is clicked
focusout: focus is leaving <input type value=�"1" id=�"input1">� and it will go to <input type value=�"2" id=�"input2">�
focusin: focus was gained by <input type value=�"2" id=�"input2">�

// Input3 is clicked
focusout: focus is leaving <input type value=�"2" id=�"input2">� and it will go to <input type value=�"3" id=�"input3">�
focusin: focus was gained by <input type value=�"3" id=�"input3">�
```

Now, let's add a blur handler that changes focus:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title></title>
</head>
<body>
  <div id="container">
    <input type="" value="1" id="input1">
    <input type="" value="2" id="input2">
    <input type="" value="3" id="input3">
  </div>

  <script>
    container.addEventListener('focusin', (ev) => {
      console.log('focusin: focus was gained by', ev.target);
    });
    container.addEventListener('focusout', (ev) => {
      console.log('focusout: focus is leaving', ev.target, 'and it will go to', ev.relatedTarget);
    });
    input2.addEventListener('blur', (ev) => {
      input2.focus();
    });
  </script>
</body>
</html>
```

The log sequence changes and gives the wrong impression that no dom element has focus:

```
// Input1 is clicked
focusin: focus was gained by <input type value=�"1" id=�"input1">�

// Input2 is clicked
focusout: focus is leaving <input type value=�"1" id=�"input1">� and it will go to <input type value=�"2" id=�"input2">�
focusin: focus was gained by <input type value=�"2" id=�"input2">�

// Input3 is clicked, but the handler kicks in and instead of the following line being a focusout, it results in a focusin call first.
focusin: focus was gained by <input type value=�"2" id=�"input2">�
focusout: focus is leaving <input type value=�"2" id=�"input2">� and it will go to null
```

In addition to that, during `focusout` processing, `activeElement` typically points to `<body />`. However, if an element is focused during a `blur` event, `activeElement` points to that focused element.  Although, undocumented it can be verified with:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title></title>
</head>
<body>
  <div id="container">
    <input type="" value="1" id="input1">
    <input type="" value="2" id="input2">
    <input type="" value="3" id="input3">
  </div>

  <script>
    container.addEventListener('focusin', (ev) => {
      console.log('focusin: was gained by', ev.target);
    });
    container.addEventListener('focusout', (ev) => {
      console.log('document.hasFocus()', document.hasFocus());     
      console.log('document.activeElement', document.activeElement);
      console.log('focusout: focus is leaving', ev.target, 'and it will go to', ev.relatedTarget);
    });
    input2.addEventListener('blur', (ev) => {
      input2.focus();
    });
  </script>
</body>
</html>
```

We leverage these behaviors to ignore `focusout` events when the document has focus but `activeElement` is not `<body />`.

flutter/flutter#153022

[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
    @tugorez
    tugorez authored Sep 5, 2024
    1 Configuration menu
    Copy the full SHA
    0462d19 View commit details
    Browse the repository at this point in the history

  2. [engine] always force platform channel responses to schedule a task. (#… 

    …54975)

If we use runNowOrPostTask on platform channel responses, then we may not wake up the dart message loop. If nothing else wakes it up, then the embedder may hang on platform channel responses.

This fixes several google3 integration tests when run in merged thread mode.
    Jonah Williams authored Sep 5, 2024
    Configuration menu
    Copy the full SHA
    015f3b1 View commit details
    Browse the repository at this point in the history
Loading