6976 - Horizontal scrollbar is missing. {was: "create scrollbar for / allow scrolling to overflow top (above) / left of container (Left side of the page is cut)"}

Status: RESOLVED WONTFIX

(Core :: Layout: Block and Inline, defect, P1)

Description

[Peter Linss]

Negative text-indent correctly triggers overflow behavior, however, the scroll
view will not scroll left to show the starting text.

Example:
<div style="overflow: auto; text-indent: -1in;">lkgfglklhg lskhg sljg hlshg slhg
slhg slhg slkdfj hgshg lskjdfhg lsk hglskjdh glskhg lskdg f</div>

Comment 1

[troy]

Hmmm, it's not at all clear how to make scrolling to the left work. Should the
scrollbar be all the way to the left initially (i.e., showing the text that was
positioned to the left), or should the initial scrollbar position be at the
scrolled frame's (0, 0) positioned (i.e. user has to explicitly scroll to the
left to see the negatively indented text)?

Either way there are some tricky issues and maybe changes to the view hierarchy
to support this.

Comment 2

[Peter Linss]

I would say that the scroll view should be positioned at 0,0, so the user would
have to scroll left to see the negative indent.

Comment 3

[troy]

Yes, I think that's best, too.

Making this work will be kind of tricky. In normal cicumstances the content
creator can fairly easily work around this problem by having a large left (e.g.)
padding. That way the negatively element does not overflow.

How strongly do you feel we need to support this, i.e. can we LATER this?

Of course, I would happily implement this if we could remove the nasty z-index
stuff in the spec that says 'auto' doesn't create a new stacking context and
that negative z-index values cause a child to display below its parent. Hint
hint. :-)

Comment 4

[Peter Linss]

Having negative text indent fail to scroll properly doesn't bother me too much.
But when you get into cases like bug 7278, and the generic case of the
viewport not scrolling left for random content that overhangs left, really do
bother me. I would think that as a generic fix to scrolling frames/views this
shouldn't be too bad to do...

Comment 5

[troy]

It's probably not that bad, but it's not for free. What we have are two frames
(scroll frame and scrolled frame), and their corresponding views (plus a clip
view, but that doesn't really count).

Assuming all the changes are to the scroll frame code (that would be cleaner
than having to change the view code as well), the scroll frame would have to:
- size the scrolled view to include the elements negatively positioned to the
left (i.e., the left overflow). Tthis makes the scrolled view larger than the
scrolled frame, but that's okay and already happens today anyway with
positioned child elements
- when painting the scrolled frame, the scroll frame would first have to
translate (using the rendering context) by the amount of the overflow on the
left edge

This solves 2/3 of the problem, and the last problem is making it so the
scrollbar is positioned at (0, 0) of the scrolled frame, which would require the
scroll frame to set the scroll offset. It would do this for the initial reflow
and maybe some other cases, depending on how smart it wanted to be

All of this is manageable and doesn't require view changes. Any other proposals
for how we could implement this?

Comment 6

[troy]

The previous description was mostly correct, but in looking at the scroll frame
code we size the scrolled frame to include any absolutely positioned child
elements that "stick out" on the left or bottom.

We do that so the background is displayed there. That's an anomaly that only
applies to scrolled items. For non-scrolled elements the background is only
rendered where there's flowed content

If we were to render the background behind the negatively positioned elements,
then the frame would have to be that big as well. That gets a little messy

We should really decide what the correct behavior is for scrolled elements and
where the background is rendered

Comment 7

[Hixie (not reading bugmail)]

[Tentatively marking this as a {css2} bug, although it isn't really. This is
just to aid tracking.]

Comment 8

[Hixie (not reading bugmail)]

[retitling bug...]

Troy: Will these changes also let us scroll up to see content that has
overflowed _above_ the (0,0) point?

Also, do the changes you've described initially position the viewport so that
its top left corner is at (0,0), or does it position the viewport so that
initially it is at the leftmost/topmost point? I would assume (0,0), since that
is most likely to be what the author intended. I didn't fully follow this part
of your explanation of the likely fix... ;-)

Comment 9

[troy]

Yes and {0, 0}

Only don't count on this getting fixed for version 1.0. I'm sure you expected me
to say that. :-)

Comment 10

[Hixie (not reading bugmail)]

Cool, cool, and yep, I did. :-) Slightly retitling bug again.

Comment 11

[troy]

Something we should do, but we won't have time for version 1.0 so marking LATER

Comment 12

[Christine Hoffman]

Verified LATER

Comment 13

[Hixie (not reading bugmail)]

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 14

[troy]

*** Bug 30973 has been marked as a duplicate of this bug. ***

Comment 15

[Christopher Hoess (gone)]

LATER is deprecated per bug 35839.

Comment 16

[Christopher Hoess (gone)]

->default

Comment 17

[Bernd]

Attachment: testcase

Comment 18

[Greg K.]

Reconfirmed using FizzillaCFM/2002070913. Setting All/All.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Retitling with better search terms, since this bug is probably the single bug in
bugzilla that I have the most trouble finding.

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 172955 has been marked as a duplicate of this bug. ***

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 185997 has been marked as a duplicate of this bug. ***

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Taking bug, P1/Future.

Comment 23

[Gal Gur-Arie]

Attachment: another example on no scroll bar because table tag has attribute of align="right"

another example on no scroll bar because table tag has attribute of
align="right"
check also bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=185997

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 185997 has been marked as a duplicate of this bug. ***

Comment 25

[José Jeria]

*** Bug 186061 has been marked as a duplicate of this bug. ***

Comment 26

[Andrew Schultz]

*** Bug 138505 has been marked as a duplicate of this bug. ***

Comment 27

[Chris Casciano]

*** Bug 188137 has been marked as a duplicate of this bug. ***

Comment 28

[Chris Casciano]

*** Bug 191626 has been marked as a duplicate of this bug. ***

Comment 29

[Shoshannah Forbes]

Anything new here? This bug is preventing people with lower resolution from
using Hebrew/Arabic web pages properly (as they have no hirzantle scrolling).

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 180531 has been marked as a duplicate of this bug. ***

Comment 31

[Boris Zbarsky [:bzbarsky]]

*** Bug 129022 has been marked as a duplicate of this bug. ***

Comment 32

[Prognathous]

Shoshannah Forbes wrote:
> This bug is preventing people with lower resolution from
> using Hebrew/Arabic web pages properly (as they have no horizontal scrolling).

In fact, when viewing pages with large pictures, this bug affects everyone (even
those of us who use higher resolutions). Here's a typical case:

http://mozilla.org.il/board/viewtopic.php?t=53

A single 1024x768 screenshot renders the whole discussion unreadable.

Prog.

Comment 33

[P.Haroah]

I don't get it, why not just treat all negative offsets as 0,0 unless
scrollbars are available?

Comment 34

[Hixie (not reading bugmail)]

*** Bug 204408 has been marked as a duplicate of this bug. ***

Comment 35

[Hixie (not reading bugmail)]

*** Bug 205919 has been marked as a duplicate of this bug. ***

Comment 36

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 209628 has been marked as a duplicate of this bug. ***

Comment 37

[Wenqing Jiang]

The bug is about a fundamental function of a browser, but seems received
little attention here.  Or is it too difficult to fix, so it will be
deferred to the coming Gecko overhaul?

Comment 38

[Hixie (not reading bugmail)]

The biggest problem is probably how to implement this in the UI. It would seem
really weird to most users if the scrollbar started in the middle, instead of
all the way to the left, for example.

Incidentally, as http://junkyard.damowmow.com/34 shows, IE has this bug too.

Comment 39

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 209993 has been marked as a duplicate of this bug. ***

Comment 40

[P.Haroah]

IE doesn't seem to have this problem with hotbot.com

Comment 41

[Boris Zbarsky [:bzbarsky]]

*** Bug 211335 has been marked as a duplicate of this bug. ***

Comment 42

[Davor Cubranic]

re comment 38: I would rather have the scrollbar starting somewhere in the
middle than not be able to see the left side of the page at all. And I would
suspect most other users would say the same. Is it possible to do a "good
enough" approximation and worry about the finer nuances once the basic
functionality is there?

Comment 43

[Neil Parks]

Attachment: normal view showing incomplete menu and no scrollbar

no scrollbar for menu frame on the left

Comment 44

[Neil Parks]

Attachment: full screen mode shows complete menu frame

full screen view shows complete menu frame

Comment 45

[Neil Parks]

An example of a missing vertical scrollbar: 

This web page:  http://progate.daps.dla.mil/home/  has two frames.  The vertical
menu bar along the left is one frame, and the main text area is another.  The
text frame has a vertical scroll bar, but the menu frame does not, so that the
bottom part of the menu is cut off.  I am attaching two screen shots showing how
the page looks in normal view (part of menu missing), and how it looks in full
screen (F11) mode with the complete menu.

Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5a) Gecko/20030702 Mozilla
Firebird/0.6

Comment 46

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

comment 43, comment 44, and comment 45 are not related to this bug.  Please
don't add unrelated comments to bugs.  They are in fact not a bug at all, since
the frame has scrolling=no.

Comment 47

[Neil Parks]

If my additions were unrelated, I apologize.  I searched for an appropriate bug,
and several that seemed likely were all marked as dups of this one.  So I
thought, this must be the place.

Comment 48

[P.Haroah]

Heh heh!
It seems there many duplicates, yet not much progress.
Even the browser name has changed. 

yeah, i know i know, this is not a chat forum either..-yawn.

Comment 49

[Wenqing Jiang]

From an outsider point of view, it's rather strange that this bug can be
so long-lived, as what is broken now is a basic funtionality (we can't even
read the page fully).  If the text is centered, the horrizontable scroll bar
should also be centered.  Or the text and bar are both left-aligned at
the very beginning (like what IE does).  Both case would allow user to
scroll and read the full text.  It's rather perplexing why that should be so
difficult.

But there's not any reason to believe that the programmers are lazy or
stupid.  There must be something deep that is wrong.  Giving a clear
explanation of the underlying difficulty would, I hope, help very much for
the discussing of a solution.  And perhaps reduce yawning!  :-)

Comment 50

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It shouldn't be particularly hard.  There are just a lot of bugs, and this is
one of them.

Maybe if nobody makes irrelevant comments on the bug for a while, I'll fix it. 
(The more irrelevant comments there are, the harder it is to find the technical
details on the bug, and the less likely it is to be fixed.)

Comment 51

[Boris Zbarsky [:bzbarsky]]

*** Bug 214299 has been marked as a duplicate of this bug. ***

Comment 52

[Bill Mason]

*** Bug 214953 has been marked as a duplicate of this bug. ***

Comment 53

[Boris Zbarsky [:bzbarsky]]

*** Bug 218400 has been marked as a duplicate of this bug. ***

Comment 54

[Boris Zbarsky [:bzbarsky]]

*** Bug 219271 has been marked as a duplicate of this bug. ***

Comment 55

[Hideo Saito]

Attachment: patch

This patch sets the value of zero when the x-position of floaters is negative
value.

Comment 56

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 131583 [details] [diff] [review]
patch

Even if we wanted to do this, it would belong on another bug.  I don't think we
should do this -- we should just fix this bug.

In any case, coordinates are relative to the parent, not to the viewport, so
you're breaking all sorts of cases, not just those that go out of the viewport.

Comment 57

[Mikko Rantalainen]

I agree that the proposed patch isn't the way to go. I now feel that the correct
behavior is to position all elements just where they currently go but the scroll
bars should reflect the fact that there's content above or to left from "real"
top left corner. Both scroll bars should start from 0,0 initially even if the
top of the vertical scroll bar wasn't 0 or left end of the horizontal scroll bar
wasn't 0. Does the code that takes care of scrollbars support negative values
for the start of the track? Is there an easy way to compute leftmost part of the
content?

Also, while you're fixing this, check if you can fix bug 19261 in the same time
(see also bug 19261 and bug 139832).

Comment 58

[Jamie Zawinski]

> Both scroll bars should start from 0,0 initially

Do you mean that with documents like this, the default position of the
horizontal scroll bar would be something other than "all the way to the left"? 
That would be very, very weird.  Users don't care about the coordinate system
that's inside the document, or where "0,0" happens to be in that coordinate system.

I think the most obvious, expected behavior would be:
Compute the bounding box of the document; make the extent of the scrollbars
reflect the position within that bounding box.  Start them initially positioned
at the upper left of that bounding box (regardless of what coordinate that point
has in the document's space.)

Comment 59

[Mikko Rantalainen]

Attachment: Illustration for default scroll position

Left picture illustrates the result if initial position is all the way to left
instead of initial position of 0,0 in case there's position that has negative
left side border. Think the black border to represent viewport, green area to
represent the actual content and red border to represent an advertisement
border with float:right. It seems clear to me that in most cases all content
that falls towards left or top from 0,0 is by mistake and the browser should
provide means to display it. However, such content should be hidden in initial
view. (Possible exception is if all the content can fit in the viewport if the
scroll position is other than 0,0. I think such special case can be ignored for
now.)

I feel that if the red bordered box in the image has float: right it's
incorrect (against the CSS spec) to render green area like in the right image
and the red bordered box like in the left image even if the original author
thought it "should" be rendered that way.

Comment 60

[Prognathous]

Jamie Zawinski wrote in comment 58:

> Do you mean that with documents like this, the default position of the
> horizontal scroll bar would be something other than "all the way to the left"? 
> That would be very, very weird.

With Right-to-Left pages (dir="rtl"), the horizontal scroll bar should be all
the way to the right. See comment 32.

Prog.

Comment 61

[Mats Palmgren (inactive)]

*** Bug 220243 has been marked as a duplicate of this bug. ***

Comment 62

[Prognathous]

With 22 dupes, this bug needs a clearer summary.

I'll append some key details at the end of the summary, but feel free to replace
it completely with something that's easier to understand/search for.

Prog.

Comment 63

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Most of the duplicates are really duplicates of another bug, which is the real
problem.

Comment 64

[Bernd]

*** Bug 231760 has been marked as a duplicate of this bug. ***

Comment 65

[Boris Zbarsky [:bzbarsky]]

*** Bug 232128 has been marked as a duplicate of this bug. ***

Comment 66

[Boris Zbarsky [:bzbarsky]]

*** Bug 232448 has been marked as a duplicate of this bug. ***

Comment 67

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Most of the duplicates of this bug were fixed by my checkin of bug 185411 to the
trunk, 2004-02-03 21:18 -0800.

I think this bug should be WONTFIX, except for scrolling to the right when
'direction' is 'rtl'.

Comment 68

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Er, scrolling to the *left* when direction is rtl.

Comment 69

[Shoshannah Forbes]

>I think this bug should be WONTFIX, except for scrolling to the right when
>'direction' is 'rtl'.

Well, this bug is pretty major for RTL users.
Some more users complained about it today in another forum.

So before marking it WONFIX, please make sure that RTL users are not left in the
cold.

Comment 70

[Ivar Snaaijer]

I understand that fixing this kind of bugs can be a real PITA, but the quility
of the dinosaur has to be guarenteed... Also this issue is not only about RTL.
Some time in the past someone made my report a dupe of this one (see 218400) and
althoug there is no RTL code the file (see URL) it still does not seem to work (
rv:1.6 Gecko/20040113 )

Comment 71

[Gal Gur-Arie]

Attachment: example showing this bug is NOT only when the direction is RTL

This attachment is an example which shows that the bug is not only when
direction is set to RTL.

Comment 72

[Gal Gur-Arie]

Attachment: example showing this bug is NOT only when the direction is RTL

This attachment is an example which shows that the bug is <b><u>not</u></b>
only when direction is set to RTL.

Comment 73

[Alon Weinstein]

(In reply to comment #72)
> Created an attachment (id=140603)
> example showing this bug is NOT only when the direction is RTL
> 
> This attachment is an example which shows that the bug is <b><u>not</u></b>
> only when direction is set to RTL.

I'm all for solving this bug, but under my Firebird (Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:1.6b) Gecko/20031130 Firebird/0.7+) I get a horizontal scrollbar
after clicking the "click to change table align="left"", so I guess it only
affects RTL?

Comment 74

[Gal Gur-Arie]

(In reply to comment #73)
> (In reply to comment #72)
> > Created an attachment (id=140603)
> > example showing this bug is NOT only when the direction is RTL
> > 
> > This attachment is an example which shows that the bug is <b><u>not</u></b>
> > only when direction is set to RTL.
> 
> I'm all for solving this bug, but under my Firebird (Mozilla/5.0 (X11; U; Linux
> i686; en-US; rv:1.6b) Gecko/20031130 Firebird/0.7+) I get a horizontal scrollbar
> after clicking the "click to change table align="left"", so I guess it only
> affects RTL?


This is exactly what the example should do.
When you change the TABLE align to left you can see the horizional scroll bar.
Click again on the button - it will change back the table align to right, the
scroll bar disapears and the left content of the document is not shown.

There is no connection for RTL or LTR non of them is written in the example's HTML.

Comment 75

[Ivar Snaaijer]

I know, I'm seriously risking beeing a drag, but the example I provided at
http://oor.snaaijer.nl/download/Mil_Dun_EU.HTML
does not even have *anything* aligned right, and still does not work. Try to
open it in 'the other' browser and you see what I mean.

Comment 76

[Ivar Snaaijer]

I just noticed that I was not completely accurate in my statement that there is
noting right about the document (pun not intended).
There is an inline css that has 'float:right' assigned to 'body'. When I remove
this, it works as I would like. Sorry for the bad lighting in my head.

Comment 77

[Prognathous]

(In reply to David Baron, comment #67)
> Most of the duplicates of this bug were fixed by my checkin of bug 185411 to the
> trunk, 2004-02-03 21:18 -0800.

The bug is still there, see the attached URL for a real-life example, as well as
the last couple of testcases.

Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040506

Prog.

Comment 78

[Boris Zbarsky [:bzbarsky]]

*** Bug 248594 has been marked as a duplicate of this bug. ***

Comment 79

[David Cecere]

Please address the errant behavior in Firefox when using overflow-x and 
overflow-y. The browser ignores both -x and -y. Using overflow-x: hidden; 
eliminates the scrollable area entirely.

Comment 80

[Asaf Romano (gone)]

*** Bug 259232 has been marked as a duplicate of this bug. ***

Comment 81

[Eyal Rozenberg]

Could someone please explain what exactly the problem is with the first
testcase? I see everything scrolling nicely with a seamonkey build from 2004-08-17.

Comment 82

[Wenqing Jiang]

From my tests the problem is gone now.

Comment 83

[Asaf Romano (gone)]

(In reply to comment #81)
> Could someone please explain what exactly the problem is with the first
> testcase? I see everything scrolling nicely with a seamonkey build from
2004-08-17.

Yep, this was fixed along time ago (comment 56 ?). As far as I know, the current
issue is right aligned tables (see last testcase).

Comment 84

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

No, this definitely isn't fixed, although the testcases have likely changed
their behavior due to other bug fixes.

We also definitely need to fix this for bidi cases, but probably not for
anything else, and that should perhaps be a separate bug.

Comment 85

[Eyal Rozenberg]

Comment on attachment 89111 [details]
testcase

As per Asaf and David's comments #83,#84, marking the first testcase obsolete.

Comment 86

[Eyal Rozenberg]

Attachment: simplified testcase

A simplified testcase without any images or tables-within-tables, and with some
explanatory in-testcase blurb. Also invalidating second copy of last testcase.

Comment 87

[Eyal Rozenberg]

It seems that when nsGfxScrollFrameInner::GetScrolledSize() is called to
determine the scrolled size of the browsed content, the root view is reporting
the wrong dimensions, i.e. it reports the dimensions of the window rather than
adding the extra margin. So obviously that's a point we can use to check a
possible fix. However there's another issue: should the dimensions reported by
mScrollAreaBox' childBox' frame's view be

x: -something  y: -something_else  w: foo  h: bar

or 

x: 0  y: 0  w: foo+something  h: bar+something_else

?

This depends on whether the nsView::GetBounds() should be returning a rect
relative to the document origin or to the canvas origin (excuse any possible
abuse of terms).

Comment 88

[Eyal Rozenberg]

I officially declare this a minor design problem rather than a bug... One could
easily (after laboring all day to find the relevant piece of code) replace this:

aDesiredSize.width = kidReflowState.mComputedMargin.left +
 PR_MAX(kidDesiredSize.mOverflowArea.XMost(),
        kidDesiredSize.width + kidReflowState.mComputedMargin.right);

with this:

aDesiredSize.width = kidReflowState.mComputedMargin.left +
 PR_MAX(kidDesiredSize.mOverflowArea.XMost() - kidDesiredSize.mOverflowArea.x,
        kidDesiredSize.width + kidReflowState.mComputedMargin.right);

in CanvasFrame::Reflow() (and the same for the height) , but the effect this has
is to increase the scrollable width by the proper amount _to_the_right_ of the
canvas, not the left. On a lot of levels there is the implicit assumption that
overflow is something that only happens to the bottom and to the right of a
frame/view/window/etc. For example, the nsBoxToBlockAdaptor (shouldn't that be
Adapter?) has a member mOverflow which is an nsSize instead of nsRect, and so
are its access methods - and of course when it is used to form a rectangle, in
nsScrollBoxFrame::DoLayout() for example, the corner position is assumed to be
0,0 , and not only that, the code of nsScrollBoxFrame::DoLayout() which does a
'containing rectangle union' rectangle construction employs widths and heights
instead of width+x 's and height+y's. I'm not at all familiar with the code but
I'm sure there are a zillion more cases in .

Also, I am not sure whether or not the nsGfxScrollFrame can live with scroll
ranges which begin in negative values, and whether or not it sets the initial
scroll position to the top and left of the scroll ranges respectively or to 0,0
- or maybe it doesn't do anything and relies on the initial values in the
relevant objects' constructors.

Comment 89

[Boris Zbarsky [:bzbarsky]]

*** Bug 262112 has been marked as a duplicate of this bug. ***

Comment 90

[Prognathous]

This bug makes many pages unreadable in Mozilla. The lack of a workaround (other
than using a different browser), definitely makes it a "major loss of function",
hence Severity -> Major.

I'm also changing the summary to something a little easier to find (taking into
account the limited width of Bug list columns). Feel free to conceive a better
summary and replace this one completely.

Prog.

Comment 91

[Boris Zbarsky [:bzbarsky]]

*** Bug 267264 has been marked as a duplicate of this bug. ***

Comment 92

[vbarsan]

Mozilla/Firefox has been greatly improved as to vertical and horizontal
scrolling with this latest trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8b). However while scrolling horizontally and a hyperlink - text or
image - enters the area any click at any time instantaneously moves either
forward or backwards the whole highlighted link within view area thus screwing
up the moving rule of the scroller. Ex.: 
http://vbarsan.com/horizontalslider.htm or .../multiplenews.htm or
.../newsscroller.htm. This might actually be a new bug!

Comment 93

[vbarsan]

A bit more explicit to my earlier comments #92: this trunk - Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8b) - beside bringing the whole
hyperlink forward or backwards into full view it also offsets the area'
coordinates for the javascript so the scroller never recovers itself.

Comment 94

[Hideo Saito]

Attachment: patch

I think that x-position should not be set to a negative value, if the frame has
a scrolled area horizontally. The changes to
nsContainerFrame::FinishReflowChild cause to appear the horizontal scroll bar
for http://mozilla.org.il/board/viewtopic.php?t=53.

Comment 95

[Hideo Saito]

Attachment: testcase for patch

Comment 96

[Eyal Rozenberg]

Aren't you just clipping the left overflow somehow? This patch looks too simple
to be the solution... :-(

Plus there's the case of y < 0 .

Comment 97

[Asaf Romano (gone)]

Attachment: margins problem

tested on https://bugzilla.mozilla.org/attachment.cgi?id=153561

Comment 98

[Simon Montagu :smontagu]

Attachment: http://www.mozilla.org/start/ with the patch

The patch breaks pages like http://www.mozilla.org/start/ which deliberately
position elements outside the viewport.

See http://www.mozilla.org/css/base/template.css :

.skipLink {
 position: absolute;
 left: -999px;
 width: 990px;
}

Comment 99

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 174215 [details] [diff] [review]
patch

Yeah, authors definitely position things in odd places intentionally.  I also
don't understand why you're testing the 'overflow' property of the child.

I think the only thing we should be doing here is what I described in comment
67.

Comment 100

[Simon Montagu :smontagu]

So, if an rtl page should be able to scroll left to the element with the minimum
x coordinate, what should happen if you have a page with |dir="rtl"|, *and* an
image wider than the viewport, *and* a block with |position: absolute; left:
-999px;|?

Do we just say "don't do that"?

Comment 101

[Ivar Snaaijer]

I second #100, referring (again) to the page I put in with comment #75, it has
no negative placement. It only has right placement of the body. In my current
version of firefox (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041109 Firefox/1.0) I get a scrollbar, but it is still not possible to
read all info on the page.

Comment 102

[vbarsan]

Some good news to my earlier comments #92 &# 93: Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8b1) -> When clicking on any
highlighted portion of a horizontally-left-scrolling Hyperlink coming into the
view, this trunk is bringing instantaneously forward into full view the whole
hyperlink - NO MORE backwards moves when the highlighted area goes beyond left edge.

Comment 103

[Amer Sabbagh]

(In reply to comment #0)
> Negative text-indent correctly triggers overflow behavior, however, the scroll
> view will not scroll left to show the starting text.
> 
> Example:
> <div style="overflow: auto; text-indent: -1in;">lkgfglklhg lskhg sljg hlshg slhg
> slhg slhg slkdfj hgshg lskjdfhg lsk hglskjdh glskhg lskdg f</div>

Acctually this is a very bad bug, and it just made me make the decision to not
spread the word of Mozilla/Firfox any more in my world until this is solved.

It is so old, and so bad, and actually does not relate to the RTL thing.

You can just reproduce it very simply (and frequently) using a simple table
aligned to right and has more width than the width of the browser window.



-------------- HTML CODE START  ----------------
<table align=right>
<tr>
<td>any contents make the table wider than the width of the browser window - you
can shrink the window size to make this table non fittable in the browser window
and you will see the scrollbar disappeared</td>
<td>any contents make the table wider than the width of the browser window - you
can shrink the window size to make this table non fittable in the browser window
and you will see the scrollbar disappeared</td>
<td>any contents make the table wider than the width of the browser window - you
can shrink the window size to make this table non fittable in the browser window
and you will see the scrollbar disappeared</td>
<td>any contents make the table wider than the width of the browser window - you
can shrink the window size to make this table non fittable in the browser window
and you will see the scrollbar disappeared</td>
<td>any contents make the table wider than the width of the browser window - you
can shrink the window size to make this table non fittable in the browser window
and you will see the scrollbar disappeared</td>
<td>any contents make the table wider than the width of the browser window - you
can shrink the window size to make this table non fittable in the browser window
and you will see the scrollbar disappeared</td>
<td>any contents make the table wider than the width of the browser window - you
can shrink the window size to make this table non fittable in the browser window
and you will see the scrollbar disappeared</td>
</tr>
</table>
-------------- HTML CODE END  ----------------



And this is very very bad. and should be moved to critical or even blocker.

Comment 104

[:Gavin Sharp [email: [e-mail]]]

*** Bug 292885 has been marked as a duplicate of this bug. ***

Comment 105

[Prognathous]

Other than opening the page in another browser, is there any way to work around
this bug? I sometimes open the page in Composer and delete the wide element that
triggers the bug, but I'm hesitant to even call this a workaround. It's just too
cumbersome.

Prog.

Comment 106

[Tomer Cohen :tomer]

(In reply to comment #105)
> Other than opening the page in another browser, is there any way to work around
> this bug? I sometimes open the page in Composer and delete the wide element that

Platypus (Inline WYSIWYG editor for GreaseMonkey scripts) can let you delete the
element without leaving the browser. It is no solution, but a simple workaround. 

In the past we had a bookmarklet which changes the direction of the page, but it
become broken somehow. Maybe a GreaseMonkey workaround will solve it until a
patch will land.

Comment 107

[Eyal Rozenberg]

(In reply to comment #106)
> Platypus can let you delete the element without leaving the browser.

This:

http://extensionroom.mozdev.org/more-info/nukeanything

is probably a simpler way to delete/hide elements without leaving the browser.

Comment 108

[Reuven Gonen]

The bookmarklet here WFM:
http://www.viewpoints.co.il/firefox/dev/

just drag "horizantal scrollbar" to the bookmarks toolbar. then you can use it
when you get to a page with the problem.

Comment 109

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that we should provide scrolling mechanism for negative direction(both X
and Y).

In CSS2.1:
http://www.w3.org/TR/CSS21/visufx.html#overflow
The behavior of the 'auto' value is user agent-dependent, but should cause a 
scrolling mechanism to be provided for overflowing boxes.
                                       ^^^^^^^^^^^^^^^^^
If the box position has negative offset(this is also overflow), we should also
provide scrolling mechanism for the box.
# we should change nsScrollPortView?
# http://lxr.mozilla.org/mozilla/source/view/src/nsScrollPortView.cpp
# This clamps offset by zero.

Comment 110

[Uri Bernstein]

(In reply to comment #67)
> Most of the duplicates of this bug were fixed by my checkin of bug 185411 to
> the trunk, 2004-02-03 21:18 -0800.
> 
> I think this bug should be WONTFIX, except for scrolling to the [left] when
> 'direction' is 'rtl'.


(In reply to comment #84)
> No, this definitely isn't fixed, although the testcases have likely changed
> their behavior due to other bug fixes.
> 
> We also definitely need to fix this for bidi cases, but probably not for
> anything else, and that should perhaps be a separate bug.

Bug 192767, if I understand it correctly, describes the "RTL" part of this bug.
Should I:
- Resolve 192767 as a duplicate of this bug?
- Mark this bug WONTFIX (per the comments I quoted), so work could be done on 192767?
- Do something else?
- Do nothing?

Comment 111

[Ivar Snaaijer]

(In reply to comment #110)
> Bug 192767, if I understand it correctly, describes the "RTL" part of this bug.
> Should I:
> - Resolve 192767 as a duplicate of this bug?
> - Mark this bug WONTFIX (per the comments I quoted), 
> - Do something else?
> - Do nothing?
> 
Why not make 192767 dependand on this one. I have not checked comment #109 yet, but for some reason it sounds reasonable. 

Comment 112

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This bug has over 100 comments, and is therefore pretty much unusable.  As originally reported, I think it's also something that we should never fix.  So let's use bug 192767 for fixing this for RTL, and mark this bug wontfix.

Comment 113

[Eyal Rozenberg]

(In reply to comment #112)
> As originally reported, I think it's also something that we should never fix.

Are you sure you want the testcase:
https://bugzilla.mozilla.org/attachment.cgi?id=159979

not to have a horizontal scrollbar just because it's not RTLish? If that's not what you meant, could you separate the wheat from the chaffe (sp?) regarding what should and what should not be fixed in your opinion?

Comment 114

[Uri Bernstein]

(In reply to comment #113)
> 
> Are you sure you want the testcase:
> https://bugzilla.mozilla.org/attachment.cgi?id=159979
> not to have a horizontal scrollbar just because it's not RTLish?

FWIW, I tested attachment 159979 [details] with IE6, Safari, and Opera 8.51 (Mac), and in all of them the table overflows to the right (and a horizontal scrollbar appears, of course). Are we sure that we're doing the correct thing by overflowing it to the left?

Comment 115

[Eyal Rozenberg]

In this specific example - I don't know; I think it should overflow to the right, but it's not clear-cut. The more general question is should we ever have overflows to the left and to the top of the origin - and on that question my opinion is a definite "yes". It may even be the case that we'll have to, even if only to fix bug 192767.

Comment 116

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There are some bugs where Mozilla causes overflow to the right in RTL cases where it should cause overflow to the left.  Some of them used to be dependencies of this bug; I moved them to bug 192767.  In any case, they should probably be fixed around the same time as bug 192767.

Comment 117

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Note that a further reason to wontfix this is that fixing it would break a *lot* of (ltr) websites that rely on using positions far off to the left to hide content.

Comment 118

[Ivar Snaaijer]

(In reply to comment #117)
That is an interesting argument ... As noted in #114 some particular problem is not visible in the other browsers. How do these browsers cope with a site like you mention ?
Could you point an URL for a site that does something like that ?
And if it breaks the site in Firefox (after this is fixed) it might even be more TechEvang than a problem in Firefox. Come to think of it, what do the standards say about this ?

Comment 119

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #118)
See http://www.mozilla.org
The first logo's link has negative offset.

I think that this should be fixed for CSS spec. See comment 109.
But I can understand DBaron's opinion too that is for marketing issue.
I want to be fix this bug for a hacker.
But I don't want to fix this bug as a member of Mozilla Japan...

But our mission also has a more support to Web Standards on Gecko...

Comment 120

[Daniel B.]

> Note that a further reason to wontfix this is that fixing it would break 
> a *lot* of (ltr) websites that rely on using positions far off to the left 
> to hide content.

As another comment alludes, isn't that a hack?  Shouldn't content to
be hidden be hidden with some other mechansism, such as setting the
visibility to false?

Comment 121

[Daniel B.]

> ... As originally reported, I think it's also something that we should never 
> fix.  

Why on earth not?   The browser cannot scroll far enough left to display all 
the content that _it_ has laid out.  How that is that not a bug?  

There are a number of regular web pages (not just specially constructed test
pages) which Mozilla lets you scroll only from somewhere in the middle to 
the right edge.  It doesn't let you scroll to see the left page of the page.  
Again, how is that insufficient scrolling range _not_ a bug?
 
(If the browser accepts a page's instructions to place some content at
negative positions, the browser darn well should let the user scroll to 
see that content.)

> ... mark this bug wontfix.

Agh! No, don't do that.

Comment 122

[Eyal Rozenberg]

(In reply to comment #31 of bug 192767)
> When the root element is rtl, the page should scroll only to the left and not
> to the right (and we also fix some of the layout bugs that cause things in rtl
> pages to overflow to the right).

We would still need a 4-coordinate scroll range, unless we want the
2-coordinate range to mean bottom-right point. Plus, what happens when content
overlows to the top? From what I remember of the code, it would probably be
simpler to just allow scrolling in any direction than implement another
solution. (Of course, it doesn't mean this option should be exposed to the user, that's a different argument.)

Comment 123

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 340270 has been marked as a duplicate of this bug. ***

Comment 129

[Jim Avera]

Ok, it's now 9 years later...

Thunderbird 31.0a1 truncates HTML email messages on the left when text-indent is negative. 
That sounds like this same old bug.
The html in the email (originally sent by TB, by the way, after copy-and-paste from Libre Office) contains the following:

<div class="" style="text-indent: -0.72in; align="LEFT">
3:00-5:30 Open Session: Musicians Rehearse Music for Dancing  
</div>

This is rendered with the initial "3:00-5:" missing on the left, and no horizontal scroll bar.

Is this the same bug?
Is this REALLY something which won't ever be fixed ?