[Tabs] Fix RTL scrollbar with Chrome 85#22830
Conversation
|
I was going to report this, but @ankit beat me to it :) |
|
What do you think about this fix instead? diff --git a/packages/material-ui/src/utils/scrollLeft.js b/packages/material-ui/src/utils/scrollLeft.js
index 2898642c4a..d336b0e4f6 100644
--- a/packages/material-ui/src/utils/scrollLeft.js
+++ b/packages/material-ui/src/utils/scrollLeft.js
@@ -18,7 +18,9 @@ export function detectScrollType() {
}
const dummy = document.createElement('div');
- dummy.appendChild(document.createTextNode('ABCD'));
+ const container = document.createElement('div');
+ container.style.width = '100px';
+ container.style.height = '1px';
+ dummy.appendChild(container);
dummy.dir = 'rtl';
dummy.style.fontSize = '14px';
dummy.style.width = '4px';
I would be leaning toward a target on the
I don't think that we need this dependency. The logic is getting normalized under a spec, browsers are progressively aligning: diff --git a/packages/material-ui/src/utils/scrollLeft.js b/packages/material-ui/src/utils/scrollLeft.js
index 2898642c4a..926e2da037 100644
--- a/packages/material-ui/src/utils/scrollLeft.js
+++ b/packages/material-ui/src/utils/scrollLeft.js
@@ -6,11 +6,17 @@ let cachedType;
*
- * Types of scrollLeft, assiming scrollWidth=100 and direction is rtl.
+ * Types of scrollLeft, assuming scrollWidth=100 and direction is rtl.
*
- * Browser | Type | <- Most Left | Most Right -> | Initial
--- a/packages/material-ui/src/utils/scrollLeft.js
+++ b/packages/material-ui/src/utils/scrollLeft.js
@@ -6,11 +6,17 @@ let cachedType;
*
* Types of scrollLeft, assiming scrollWidth=100 and direction is rtl.
*
- * Browser | Type | <- Most Left | Most Right -> | Initial
- * -------------- | ------------- | ------------ | ------------- | -------
- * WebKit | default | 0 | 100 | 100
- * Firefox/Opera | negative | -100 | 0 | 0
- * IE/Edge | reverse | 100 | 0 | 0
+ * Type | <- Most Left | Most Right -> | Initial
+ * ---------------- | ------------ | ------------- | -------
+ * default | 0 | 100 | 100
+ * negative (spec*) | -100 | 0 | 0
+ * reverse | 100 | 0 | 0
+ *
+ * Edge 85: default
+ * Safari 14: negative
+ * Chrome 85: negative
+ * Firefox 81: negative
+ * IE 11: reverse
+ *
+ * spec* https://drafts.csswg.org/cssom-view/#dom-window-scroll
*/ |
f08eb4b to
fc8aade
Compare
fc8aade to
ac953bb
Compare
|
@oliviertassinari I think your fix is cleaner and less third-party dependencies is better |
@nabc I would agree if we had an open issue about it with dozens of upvotes. It's not the case. Regarding v4, the next release will contain the deprecation messages we have done to reduce the gap between v4 and v5. But we can cherry-pick the diff to the |
|
Thanks for the quick follow up and merging.
Thanks, does look much cleaner.
Thanks for the reference to using the commit hash for the dependency, very helpful.
Makes sense. |
Chrome 85 introduced a bug with how scrollLeft is computed for RTL. This was fixed in the original source of this module -- alitaheri/normalize-scroll-left#6. The bug has been open for ~29 days, so not clear if it will be fixed anytime soon - https://bugs.chromium.org/p/chromium/issues/detail?id=1123301. This particular fix is backwards/forwards compatible according to the original PR.
Example of bug's impact: This bug is actually causing the RTL implementation of Scrollable Tabs to be broken in production when using a right-to-left language: https://material-ui.com/components/tabs/#scrollable-tabs
A better longterm fix would be to actually import https://github.com/alitaheri/normalize-scroll-left as a dependency, but I didn't go that route since I wasn't sure if we are deliberately trying to reduce the number of third-party dependencies.
Is
masterthe correct branch for a bugfix for 4.11? Will it be possible to publish a 4.11.1 release including this bugfix?I can also open a separate PR for
nextbranch.Thanks!