Page MenuHomePhabricator

(Firefox bug) Horizontal scrollbar missing on right-to-left (RTL/Hebrew/Arabic)
Closed, InvalidPublic

Description

Author: gangleri

Description:
Hallo!

I mainly use Mozilla Firefox for Windows XP SP 2 and the Monobook skins.

Please compare RTL type pages
[[ar:Special:Allmessages]]
[[fa:Special:Allmessages]]
[[he:Special:Allmessages]]
[[ur:Special:Allmessages]]
[[yi:Special:Allmessages]]

with LTR type ones
[[en:Special:Allmessages]]
[[de:Special:Allmessages]]

Tray to resize the browser windows.

Because the (1) navigation / search / toolbox / in other language (sub-)frame /
area are placed right in RTL wikis it happens that the content of the (2) *pages
main (sub-)frame / area* will overlap with (1).

This may happen in all namespaces (and probably in most of the other skins).

Please add en extra vertical scrollbar for RTL wiki's either permanent or
selectable in configurations (PHP or skin definition) which would prevent
overlapping the content of the different areas.

Thanks in advance.

Best regards reinhardt [[user:gangleri]]


Version: unspecified
Severity: enhancement
URL: http://yi.wikipedia.org/wiki/User:Gangleri/tests/%E2%80%AB%D7%B0%D7%99%D7%A5%E2%80%AB%E2%80%AB%E2%80%AB%E2%80%AB

Details

Reference
bz3820

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:54 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz3820.
bzimport added a subscriber: Unknown Object (MLST).

avarab wrote:

What does the content area overlapping the sidebar have to do with a "vertical
scrollbar" which I presume is the scrollbar provided by the browser.

gangleri wrote:

Excuse me if I can not find a better wording. There should be whatever way to
let the browser know which areas should not overlap.

Because the page does not use "HTML frame syntax" (in Monobook etc. skins) to
define the areas another way should be found; I have no clue which one.

I would like to keep the "navigation area" at the right but have a scrollbar for
the remaining "main content area". I thing that scrolling would be better then
overlapping.

Best regards reinhardt [[user:gangleri]]

avarab wrote:

So you presume that the only way to fix this problem is to use frames?

gangleri wrote:

I am not up to date about what is possible in page design and what not.

It might be an idea to use tables to do the job. The "navigation area / table"
would have a fixed width, the "content area / table" not. Most important is to
avoid overlaping; a "scrollbar" would be usefull but is not so important.

gangleri wrote:

This does not happen with Inter Explorer Version
6.0.2900.2180.xpsp_sp2_gdr.050301-1519

adding this bug blocks
bug 1381 Mozilla issues (Gecko, Firefox) (tracking)

gangleri wrote:

Please let me know (here) if you see a solution to avoid overlaping of areas in
Mozilla Firefox.

Please open another bug if necessary. Regards Reinhardt [[user:gangleri]]

You can try adding the following to your monobook.css:

#bodyContent {

overflow: auto;

}

I think that should produce a scrollbar instead of overlapping when the content
width is too large.

gangleri wrote:

screen dump

(In reply to comment #8)

You can try adding the following to your monobook.css:
#bodyContent {

overflow: auto;

}
I think that should produce a scrollbar instead of overlapping when the

content

width is too large.

Hallo Lejonel;

For
http://yi.wikipedia.org/wiki/User:Gangleri/tests/%E2%80%AB%D7%B0%D7%99%D7%A5%E2%80%AB%E2%80%AB%E2%80%AB%E2%80%AB

the up/dows scrollbar covers part of the text. This hight of the page is small
and no scroll bar should be required.

Regarding your sugestion and
http://yi.wiktionary.org/wiki/Special:Allmessages
http://yi.wikipedia.org/wiki/Special:Allmessages

I beleive that due to the size of these pages page content will be lost. With
Mozilla Firefox I can see the messages ("more or less only") until
[[MediaWiki:exif-gpsaltitude]].

Best regards Reinhardt [[user:gangleri]]

Attached:

bugzilla_3820_c8_001.jpg (221×860 px, 30 KB)

gangleri wrote:

see
bug 414 comment 20 of
bug: firefox doesn't have scroll bars for long pre tagged areas, they go off
page nastilly. style sheet fixes?
and the attachment
http://bugzilla.wikimedia.org/attachment.cgi?id=1064&action=view

also
bug 3928: Textbox and <pre> renders text broken

gangleri wrote:

It would be nice to fix pages like
[[wiktionary:yi:Image:Himalaya_composite.jpg]] in Firefox.
Make the broser window smaller and smaller until you see the problem of the
overlaping areas ("main area" and "navigation area").

gangleri wrote:

see reference bug
*RTL block overflow is not correct when it has margin:auto* at
https://bugzilla.mozilla.org/show_bug.cgi?id=96394
and attachemnt
https://bugzilla.mozilla.org/attachment.cgi?id=159830

gangleri wrote:

(In reply to comment #11)

It would be nice to fix pages like
[[wiktionary:yi:Image:Himalaya_composite.jpg]] in Firefox.
Make the broser window smaller and smaller until you see the problem of the
overlaping areas ("main area" and "navigation area").

Uri opened the bug
*Oveflowing content in fixed-width RTL blocks overflows to the right instead of
to the left*
https://bugzilla.mozilla.org/show_bug.cgi?id=318116
and provided testcases
https://bugzilla.mozilla.org/attachment.cgi?id=204452&action=view
https://bugzilla.mozilla.org/attachment.cgi?id=204454&action=view
Thanks Uri!

gangleri wrote:

changed summary from
for RTL wiki's add an additional vertical scrollbar for the pages main
(sub-)frame / area
to
(Firefox bug) Horizontal scrollbar missing on right-to-left (RTL/Hebrew/Arabic)
page that doesn't fit in the screen

because of
https://bugzilla.mozilla.org/show_bug.cgi?id=192767

[Bug Bugzilla 192767] Horizontal scrollbar missing on right-to-left

(RTL/Hebrew/Arabic) page that doesn't fit in the screen

please see also https://bugzilla.mozilla.org/showdependencytree.cgi?id=192767

reopening the bug in order to change dependencies of MediaZilla bugs depending
on this

If you know any workaround please post them here. Thanks in advance!

best regards reinhardt [[user:gangleri]]

rotemliss wrote:

It's a Firefox bug, which was fixed in Firefox trunk.