Bug 1829588 Comment 11 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Here's a screencast with devtools open to show the remaining issue.  I've added a red border to the textarea to make it easier to see when its height changes.

Google has now added `overflow-x: hidden` to this textarea by default, but if the user e.g. clicks the bottom of the search area, then an ancestor-div gains `class="sbfc ..."` for some reason, which makes a more-specific rule take effect:
```
.sbfc textarea.gLFyf {
  white-space: pre-line;
  overflow: auto;
}
```
...and the `overflow:auto` there stomps on their workaround & makes us reserve space for the scrollbar again.
Here's a screencast with devtools open to show the remaining issue.  I've added a red border to the textarea to make it easier to see when its height changes.

Google has now added `overflow-x: hidden` to this textarea by default, but if the user e.g. clicks the bottom of the search area, then an ancestor-div gains `class="... sbfc"` for some reason, which makes a more-specific rule take effect:
```
.sbfc textarea.gLFyf {
  white-space: pre-line;
  overflow: auto;
}
```
...and the `overflow:auto` there stomps on their workaround & makes us reserve space for the scrollbar again.
Here's a screencast with devtools open to show the remaining issue.  I've added a red border to the textarea to make it easier to see when its height changes.

Google has now added `overflow-x: hidden` to this textarea by default, but if the user e.g. clicks the bottom of the search area, then an ancestor-div gains `class="... sbfc"` for some reason, which makes a more-specific rule take effect:
```css
.sbfc textarea.gLFyf {
  white-space: pre-line;
  overflow: auto;
}
```
...and the `overflow:auto` there stomps on their workaround & makes us reserve space for the scrollbar again.
Here's a screencast with devtools open to show the remaining issue.  I've added a red border to the textarea to make it easier to see when its height changes.

Google has now added `overflow-x: hidden` to this textarea by default, which does avoid the problem per comment 5; but if the user e.g. clicks the bottom of the search area, then an ancestor-div gains `class="... sbfc"` for some reason, which makes a more-specific rule take effect:
```css
.sbfc textarea.gLFyf {
  white-space: pre-line;
  overflow: auto;
}
```
...and the `overflow:auto` there stomps on their workaround & makes us reserve space for the scrollbar again.

Back to Bug 1829588 Comment 11