Last Comment Bug 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)"}
: Horizontal scrollbar is missing. {was: "create scrollbar for / allow scrollin...
Status: RESOLVED WONTFIX
: css2, testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: P1 major with 14 votes (vote)
: Future
Assigned To: David Baron :dbaron: ⌚️UTC-10
: Chris Petersen
: Jet Villegas (:jet)
Mentors:
http://mozilla.org.il/board/viewtopic...
: 30973 129022 138505 172955 180531 185997 186061 188137 204408 205919 209628 209993 211335 214299 214953 218400 219271 231760 232128 232448 harpreet0001 259232 262112 267264 292885 340270 396604 452407 585676 770109 801077 (view as bug list)
Depends on:
Blocks: Persian 7278 245243
  Show dependency treegraph
 
Reported: 1999-05-24 10:08 PDT by Peter Linss
Modified: 2015-07-28 09:44 PDT (History)
50 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (594 bytes, text/html)
2002-06-25 12:46 PDT, Bernd
no flags Details
another example on no scroll bar because table tag has attribute of align="right" (914 bytes, text/html)
2002-12-19 02:37 PST, Gal Gur-Arie
no flags Details
normal view showing incomplete menu and no scrollbar (135.56 KB, image/jpeg)
2003-07-16 14:06 PDT, Neil Parks
no flags Details
full screen mode shows complete menu frame (142.06 KB, image/jpeg)
2003-07-16 14:09 PDT, Neil Parks
no flags Details
patch (1.24 KB, patch)
2003-09-16 22:27 PDT, Hideo Saito
dbaron: review-
Details | Diff | Splinter Review
Illustration for default scroll position (1.44 KB, image/png)
2003-09-17 04:28 PDT, Mikko Rantalainen
no flags Details
example showing this bug is NOT only when the direction is RTL (1.86 KB, text/html)
2004-02-04 07:47 PST, Gal Gur-Arie
no flags Details
example showing this bug is NOT only when the direction is RTL (1.86 KB, text/html)
2004-02-04 07:48 PST, Gal Gur-Arie
no flags Details
simplified testcase (980 bytes, text/html)
2004-09-24 09:11 PDT, Eyal Rozenberg
no flags Details
patch (4.09 KB, patch)
2005-02-13 07:18 PST, Hideo Saito
dbaron: review-
Details | Diff | Splinter Review
testcase for patch (528 bytes, text/html)
2005-02-13 07:22 PST, Hideo Saito
no flags Details
margins problem (30.92 KB, image/png)
2005-02-23 01:15 PST, Mano (::mano, needinfo? for any questions; not reading general bugmail)
no flags Details
http://www.mozilla.org/start/ with the patch (6.55 KB, image/png)
2005-02-23 23:53 PST, Simon Montagu :smontagu
no flags Details

Description Peter Linss 1999-05-24 10:08:28 PDT
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 1999-06-21 16:15:59 PDT
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 1999-06-21 16:44:59 PDT
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 1999-06-21 17:24:59 PDT
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 1999-06-21 17:55:59 PDT
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 1999-06-21 18:12:59 PDT
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 1999-06-21 19:35:59 PDT
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) 1999-10-04 18:03:59 PDT
[Tentatively marking this as a {css2} bug, although it isn't really. This is
just to aid tracking.]
Comment 8 Hixie (not reading bugmail) 1999-12-09 19:13:59 PST
[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 1999-12-09 20:53:59 PST
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) 1999-12-09 21:26:59 PST
Cool, cool, and yep, I did. :-) Slightly retitling bug again.
Comment 11 troy 1999-12-10 20:48:59 PST
Something we should do, but we won't have time for version 1.0 so marking LATER
Comment 12 Christine Hoffman 1999-12-13 12:01:59 PST
Verified LATER
Comment 13 Hixie (not reading bugmail) 2000-01-13 16:06:59 PST
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 2000-03-08 08:40:36 PST
*** Bug 30973 has been marked as a duplicate of this bug. ***
Comment 15 Christopher Hoess (gone) 2002-04-29 14:01:18 PDT
LATER is deprecated per bug 35839.
Comment 16 Christopher Hoess (gone) 2002-04-29 14:02:33 PDT
->default
Comment 17 Bernd 2002-06-25 12:46:47 PDT
Created attachment 89111 [details]
testcase
Comment 18 Greg K. 2002-07-13 11:17:19 PDT
Reconfirmed using FizzillaCFM/2002070913. Setting All/All.
Comment 19 David Baron :dbaron: ⌚️UTC-10 2002-11-01 19:19:02 PST
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-10 2002-11-01 19:25:07 PST
*** Bug 172955 has been marked as a duplicate of this bug. ***
Comment 21 David Baron :dbaron: ⌚️UTC-10 2002-12-18 19:10:23 PST
*** Bug 185997 has been marked as a duplicate of this bug. ***
Comment 22 David Baron :dbaron: ⌚️UTC-10 2002-12-18 19:11:27 PST
Taking bug, P1/Future.
Comment 23 Gal Gur-Arie 2002-12-19 02:37:31 PST
Created attachment 109732 [details]
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-10 2002-12-19 14:14:28 PST
*** Bug 185997 has been marked as a duplicate of this bug. ***
Comment 25 José Jeria 2002-12-21 03:06:12 PST
*** Bug 186061 has been marked as a duplicate of this bug. ***
Comment 26 Andrew Schultz 2003-02-14 15:18:14 PST
*** Bug 138505 has been marked as a duplicate of this bug. ***
Comment 27 Chris Casciano 2003-02-15 00:10:07 PST
*** Bug 188137 has been marked as a duplicate of this bug. ***
Comment 28 Chris Casciano 2003-02-19 15:22:50 PST
*** Bug 191626 has been marked as a duplicate of this bug. ***
Comment 29 Shoshannah Forbes 2003-03-09 14:12:47 PST
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-10 2003-04-09 11:43:33 PDT
*** Bug 180531 has been marked as a duplicate of this bug. ***
Comment 31 Boris Zbarsky [:bz] (still a bit busy) 2003-04-24 23:42:24 PDT
*** Bug 129022 has been marked as a duplicate of this bug. ***
Comment 32 Prognathous 2003-04-26 13:39:25 PDT
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 2003-04-27 07:35:44 PDT
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) 2003-05-04 13:03:48 PDT
*** Bug 204408 has been marked as a duplicate of this bug. ***
Comment 35 Hixie (not reading bugmail) 2003-05-16 05:06:40 PDT
*** Bug 205919 has been marked as a duplicate of this bug. ***
Comment 36 David Baron :dbaron: ⌚️UTC-10 2003-06-18 09:47:43 PDT
*** Bug 209628 has been marked as a duplicate of this bug. ***
Comment 37 Wenqing Jiang 2003-06-18 11:18:30 PDT
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) 2003-06-18 11:53:13 PDT
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-10 2003-06-19 13:25:42 PDT
*** Bug 209993 has been marked as a duplicate of this bug. ***
Comment 40 P.Haroah 2003-06-23 11:41:47 PDT
IE doesn't seem to have this problem with hotbot.com
Comment 41 Boris Zbarsky [:bz] (still a bit busy) 2003-07-01 17:46:41 PDT
*** Bug 211335 has been marked as a duplicate of this bug. ***
Comment 42 Davor Cubranic 2003-07-02 11:16:51 PDT
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 2003-07-16 14:06:37 PDT
Created attachment 127903 [details]
normal view showing incomplete menu and no scrollbar

no scrollbar for menu frame on the left
Comment 44 Neil Parks 2003-07-16 14:09:50 PDT
Created attachment 127904 [details]
full screen mode shows complete menu frame

full screen view shows complete menu frame
Comment 45 Neil Parks 2003-07-16 14:11:57 PDT
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-10 2003-07-16 14:15:13 PDT
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 2003-07-16 14:19:08 PDT
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 2003-07-18 12:04:25 PDT
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 2003-07-20 06:30:52 PDT
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-10 2003-07-20 14:19:24 PDT
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 [:bz] (still a bit busy) 2003-07-29 10:06:44 PDT
*** Bug 214299 has been marked as a duplicate of this bug. ***
Comment 52 Bill Mason 2003-08-03 13:50:51 PDT
*** Bug 214953 has been marked as a duplicate of this bug. ***
Comment 53 Boris Zbarsky [:bz] (still a bit busy) 2003-09-05 07:13:54 PDT
*** Bug 218400 has been marked as a duplicate of this bug. ***
Comment 54 Boris Zbarsky [:bz] (still a bit busy) 2003-09-15 08:55:25 PDT
*** Bug 219271 has been marked as a duplicate of this bug. ***
Comment 55 Hideo Saito 2003-09-16 22:27:30 PDT
Created attachment 131583 [details] [diff] [review]
patch

This patch sets the value of zero when the x-position of floaters is negative
value.
Comment 56 David Baron :dbaron: ⌚️UTC-10 2003-09-16 22:31:26 PDT
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 2003-09-17 03:55:45 PDT
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 2003-09-17 04:03:46 PDT
> 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 2003-09-17 04:28:04 PDT
Created attachment 131595 [details]
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 2003-09-17 05:00:11 PDT
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 (:mats) 2003-11-02 19:14:29 PST
*** Bug 220243 has been marked as a duplicate of this bug. ***
Comment 62 Prognathous 2004-01-21 02:25:02 PST
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-10 2004-01-21 09:39:39 PST
Most of the duplicates are really duplicates of another bug, which is the real
problem.
Comment 64 Bernd 2004-01-21 22:08:37 PST
*** Bug 231760 has been marked as a duplicate of this bug. ***
Comment 65 Boris Zbarsky [:bz] (still a bit busy) 2004-01-25 21:03:57 PST
*** Bug 232128 has been marked as a duplicate of this bug. ***
Comment 66 Boris Zbarsky [:bz] (still a bit busy) 2004-01-28 21:43:42 PST
*** Bug 232448 has been marked as a duplicate of this bug. ***
Comment 67 David Baron :dbaron: ⌚️UTC-10 2004-02-03 21:20:31 PST
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-10 2004-02-03 21:22:11 PST
Er, scrolling to the *left* when direction is rtl.
Comment 69 Shoshannah Forbes 2004-02-04 03:00:36 PST
>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 2004-02-04 05:05:04 PST
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 2004-02-04 07:47:23 PST
Created attachment 140602 [details]
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 2004-02-04 07:48:41 PST
Created attachment 140603 [details]
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 2004-02-04 08:34:10 PST
(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 2004-02-04 08:42:14 PST
(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 2004-02-04 11:02:16 PST
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 2004-02-20 06:02:10 PST
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 2004-05-07 03:53:15 PDT
(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 [:bz] (still a bit busy) 2004-07-13 18:25:31 PDT
*** Bug 248594 has been marked as a duplicate of this bug. ***
Comment 79 David Cecere 2004-08-02 14:58:25 PDT
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 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-09-14 16:31:43 PDT
*** Bug 259232 has been marked as a duplicate of this bug. ***
Comment 81 Eyal Rozenberg 2004-09-22 15:19:14 PDT
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 2004-09-22 15:25:47 PDT
From my tests the problem is gone now.
Comment 83 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-09-22 15:30:17 PDT
(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-10 2004-09-22 16:11:10 PDT
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 2004-09-24 08:28:49 PDT
Comment on attachment 89111 [details]
testcase

As per Asaf and David's comments #83,#84, marking the first testcase obsolete.
Comment 86 Eyal Rozenberg 2004-09-24 09:11:05 PDT
Created attachment 159979 [details]
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 2004-09-25 02:01:31 PDT
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 2004-09-25 08:08:54 PDT
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 [:bz] (still a bit busy) 2004-10-04 10:00:46 PDT
*** Bug 262112 has been marked as a duplicate of this bug. ***
Comment 90 Prognathous 2004-10-11 00:55:02 PDT
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 [:bz] (still a bit busy) 2004-11-05 09:39:12 PST
*** Bug 267264 has been marked as a duplicate of this bug. ***
Comment 92 vbarsan 2005-02-04 07:14:35 PST
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 2005-02-05 13:43:42 PST
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 2005-02-13 07:18:58 PST
Created attachment 174215 [details] [diff] [review]
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 2005-02-13 07:22:00 PST
Created attachment 174217 [details]
testcase for patch
Comment 96 Eyal Rozenberg 2005-02-13 07:36:07 PST
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 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2005-02-23 01:15:23 PST
Created attachment 175276 [details]
margins problem

tested on https://bugzilla.mozilla.org/attachment.cgi?id=153561
Comment 98 Simon Montagu :smontagu 2005-02-23 23:53:55 PST
Created attachment 175403 [details]
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-10 2005-02-24 00:38:20 PST
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 2005-02-24 01:45:49 PST
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 2005-02-24 15:36:54 PST
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 2005-02-28 10:24:14 PST
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 2005-03-05 04:11:09 PST
(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: gavin@gavinsharp.com] 2005-05-04 12:22:35 PDT
*** Bug 292885 has been marked as a duplicate of this bug. ***
Comment 105 Prognathous 2005-06-30 05:18:52 PDT
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 2005-06-30 05:52:37 PDT
(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 2005-06-30 06:05:29 PDT
(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 2005-06-30 06:33:25 PDT
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] (Mozilla Japan) 2005-09-20 12:08:40 PDT
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 (Google) 2005-10-24 07:35:11 PDT
(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 2005-10-24 13:15:46 PDT
(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-10 2005-12-18 01:07:56 PST
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 2005-12-18 05:04:55 PST
(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 (Google) 2005-12-18 05:33:31 PST
(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 2005-12-18 05:43:23 PST
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-10 2005-12-18 09:43:53 PST
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-10 2005-12-18 14:51:44 PST
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 2005-12-18 23:27:32 PST
(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] (Mozilla Japan) 2005-12-18 23:45:46 PST
(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. 2005-12-19 13:47:03 PST
> 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. 2005-12-19 14:03:15 PST
> ... 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 2005-12-20 02:30:04 PST
(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-10 2006-06-05 08:10:07 PDT
*** Bug 340270 has been marked as a duplicate of this bug. ***
Comment 124 David Baron :dbaron: ⌚️UTC-10 2008-08-27 16:22:05 PDT
*** Bug 452407 has been marked as a duplicate of this bug. ***
Comment 125 Boris Zbarsky [:bz] (still a bit busy) 2010-08-09 11:27:30 PDT
*** Bug 585676 has been marked as a duplicate of this bug. ***
Comment 126 Boris Zbarsky [:bz] (still a bit busy) 2012-07-06 21:13:26 PDT
*** Bug 770109 has been marked as a duplicate of this bug. ***
Comment 127 Mats Palmgren (:mats) 2012-10-14 08:45:34 PDT
*** Bug 801077 has been marked as a duplicate of this bug. ***
Comment 128 Daniel Holbert [:dholbert] 2014-01-22 18:31:30 PST
*** Bug 962501 has been marked as a duplicate of this bug. ***
Comment 129 Jim Avera 2014-04-29 14:23:28 PDT
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 ?
Comment 130 David Baron :dbaron: ⌚️UTC-10 2015-07-28 09:44:55 PDT
*** Bug 396604 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.