[Webkit-unassigned] [Bug 159121] [GTK] The scrollbar apeears on the left side on RTL (2.13.2)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=159121

--- Comment #3 from Myles C. Maxfield <mmaxfield at apple.com> ---
(In reply to comment #2)
> (In reply to comment #1)
> > I'm confused, because in any other application (tested nautilus and gedit) I
> > can see scrollbars are on the left when running with LANG=he_IL.utf-8... so
> > why shouldn't they be on the left for web sites as well? If it's just
> > "because that's what other browsers do," I guess that expectation will
> > change once this change hits Apple devices, right? Striving for consistency
> > with the rest of the desktop seems more important to me.
> > 
> > I'll note that some of the layout tests are skipped with the comment "RTL
> > scrollbars are only supported on Mac." We certainly do support RTL in GTK
> > and expect our scrollbars to do... something that is familiar to folks who
> > use RTL locales. I see there is a new ScrollableArea::systemLanguageIsRTL
> > function that is only implemented on OS X. Guess: is it possible that the
> > scrollbars are always on the left on OS X, but in GTK the position varies
> > based on the language used on the web page rather than system locale? If
> > this is the problem, I can see why that would be problematic. I guess if we
> > were to implement that function, the scrollbars would then always be on the
> > left (in RTL locales); that's the opposite of what you requested, but would
> > that be desirable for Hebrew, Yosef?
> 
> For the macOS port, I've implemented a WK2 API userInterfaceDirectionPolicy
> on the WKWebViewConfigurationPolicy which allows changing between two modes:
> - Web content selecting the placement of scrollbars (via dir="rtl")
> - Embedding app selecting the placement of scrollbars (via the macOS
> platform's mechanism for doing so)
> 
> The intention is that web browsers will opt for the first mode and web views
> in native apps will opt for the second mode. The first mode is the default.
> 
> Please see https://trac.webkit.org/changeset/200116

Anders added a C API for this in https://trac.webkit.org/changeset/201118

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160628/2a7b9a55/attachment.html>