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

RESOLVED WONTFIX

Status

()

Core
Layout: Block and Inline
P1
major
RESOLVED WONTFIX
18 years ago
2 years ago

People

(Reporter: Peter Linss, Assigned: dbaron)

Tracking

(Blocks: 1 bug, {css2, testcase})

Trunk
Future
css2, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(9 attachments, 4 obsolete attachments)

(Reporter)

Description

18 years ago
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>

Updated

18 years ago
QA Contact: petersen → chrisd
(Reporter)

Updated

18 years ago
Blocks: 7278

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 1

18 years ago
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.
(Reporter)

Comment 2

18 years ago
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

18 years ago
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. :-)
(Reporter)

Comment 4

18 years ago
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

18 years ago
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

18 years ago
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

Updated

18 years ago
Target Milestone: M12

Updated

18 years ago
Target Milestone: M12 → M13
Summary: negative text indent causes bad scrolling → {css2} negative text indent causes bad scrolling
[Tentatively marking this as a {css2} bug, although it isn't really. This is
just to aid tracking.]
Summary: {css2} negative text indent causes bad scrolling → {css2} allow scrolling for content that overflows to the left of (0,0)
[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

18 years ago
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. :-)
Summary: {css2} allow scrolling for content that overflows to the left of (0,0) → {css2} allow scrolling for content that overflows to the left of/above (0,0)
Cool, cool, and yep, I did. :-) Slightly retitling bug again.

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → LATER

Comment 11

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

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 12

18 years ago
Verified LATER
Keywords: css2
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

18 years ago
*** Bug 30973 has been marked as a duplicate of this bug. ***
LATER is deprecated per bug 35839.
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Summary: {css2} allow scrolling for content that overflows to the left of/above (0,0) → allow scrolling for content that overflows to the left of/above (0,0)
->default
Assignee: troy → attinasi
Status: REOPENED → NEW
QA Contact: chrisd → petersen
(Assignee)

Updated

15 years ago
Blocks: 96394

Comment 17

15 years ago
Created attachment 89111 [details]
testcase

Comment 18

15 years ago
Reconfirmed using FizzillaCFM/2002070913. Setting All/All.
Keywords: testcase
OS: Windows NT → All
Hardware: PC → All
(Assignee)

Comment 19

15 years ago
Retitling with better search terms, since this bug is probably the single bug in
bugzilla that I have the most trouble finding.
Summary: allow scrolling for content that overflows to the left of/above (0,0) → create scrollbar for / allow scrolling to overflow top / left (above) of container
(Assignee)

Comment 20

15 years ago
*** Bug 172955 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

15 years ago
Summary: create scrollbar for / allow scrolling to overflow top / left (above) of container → create scrollbar for / allow scrolling to overflow top (above) / left of container
(Assignee)

Comment 21

15 years ago
*** Bug 185997 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 22

15 years ago
Taking bug, P1/Future.
Assignee: attinasi → dbaron
Priority: P3 → P1
Target Milestone: M13 → Future

Comment 23

15 years ago
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
(Assignee)

Comment 24

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

Comment 25

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

Comment 26

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

Comment 27

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

Comment 28

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

Comment 29

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

Comment 30

14 years ago
*** Bug 180531 has been marked as a duplicate of this bug. ***
*** Bug 129022 has been marked as a duplicate of this bug. ***

Comment 32

14 years ago
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

14 years ago
I don't get it, why not just treat all negative offsets as 0,0 unless
scrollbars are available?
*** Bug 204408 has been marked as a duplicate of this bug. ***
*** Bug 205919 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 36

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

Comment 37

14 years ago
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?
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.
(Assignee)

Comment 39

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

Updated

14 years ago
Blocks: 137995

Comment 40

14 years ago
IE doesn't seem to have this problem with hotbot.com
*** Bug 211335 has been marked as a duplicate of this bug. ***

Comment 42

14 years ago
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

14 years ago
Created attachment 127903 [details]
normal view showing incomplete menu and no scrollbar

no scrollbar for menu frame on the left

Comment 44

14 years ago
Created attachment 127904 [details]
full screen mode shows complete menu frame

full screen view shows complete menu frame

Comment 45

14 years ago
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
(Assignee)

Comment 46

14 years ago
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

14 years ago
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

14 years ago
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.

Updated

14 years ago
Blocks: 154625

Comment 49

14 years ago
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!  :-)
(Assignee)

Comment 50

14 years ago
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.)
*** Bug 214299 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

14 years ago
Component: Layout → Layout: Block & Inline

Comment 52

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

Updated

14 years ago
Blocks: 202386
*** Bug 218400 has been marked as a duplicate of this bug. ***
*** Bug 219271 has been marked as a duplicate of this bug. ***

Comment 55

14 years ago
Created attachment 131583 [details] [diff] [review]
patch

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

Comment 56

14 years ago
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.
Attachment #131583 - Flags: review-

Comment 57

14 years ago
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

14 years ago
> 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

14 years ago
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

14 years ago
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.
*** Bug 220243 has been marked as a duplicate of this bug. ***

Comment 62

14 years ago
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.
Summary: create scrollbar for / allow scrolling to overflow top (above) / left of container → create scrollbar for / allow scrolling to overflow top (above) / left of container (Left side of the page is cut - no horizontal scrollbar)
(Assignee)

Comment 63

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

Comment 64

14 years ago
*** Bug 231760 has been marked as a duplicate of this bug. ***
*** Bug 232128 has been marked as a duplicate of this bug. ***
*** Bug 232448 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 67

14 years ago
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'.
(Assignee)

Comment 68

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

Comment 69

14 years ago
>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

14 years ago
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

14 years ago
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

14 years ago
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.

Updated

14 years ago
Attachment #140602 - Attachment description: example showing this bug is only when the direction is RTL → example showing this bug is NOT only when the direction is RTL

Comment 73

14 years ago
(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

14 years ago
(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

14 years ago
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

14 years ago
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.


Updated

13 years ago
Blocks: 240501

Comment 77

13 years ago
(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.
Blocks: 245243
*** Bug 248594 has been marked as a duplicate of this bug. ***

Comment 79

13 years ago
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.
*** Bug 259232 has been marked as a duplicate of this bug. ***

Comment 81

13 years ago
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

13 years ago
From my tests the problem is gone now.
(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).
(Assignee)

Comment 84

13 years ago
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

13 years ago
Comment on attachment 89111 [details]
testcase

As per Asaf and David's comments #83,#84, marking the first testcase obsolete.
Attachment #89111 - Attachment is obsolete: true

Comment 86

13 years ago
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.
Attachment #109732 - Attachment is obsolete: true
Attachment #140603 - Attachment is obsolete: true

Comment 87

13 years ago
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

13 years ago
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.
*** Bug 262112 has been marked as a duplicate of this bug. ***

Comment 90

13 years ago
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.
Severity: normal → major
Summary: create scrollbar for / allow scrolling to overflow top (above) / left of container (Left side of the page is cut - no horizontal scrollbar) → Horizontal scrollbar is missing. {was: "create scrollbar for / allow scrolling to overflow top (above) / left of container (Left side of the page is cut)"}
*** Bug 267264 has been marked as a duplicate of this bug. ***

Comment 92

13 years ago
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

13 years ago
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

13 years ago
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.
Attachment #131583 - Attachment is obsolete: true

Comment 95

13 years ago
Created attachment 174217 [details]
testcase for patch

Comment 96

13 years ago
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 .
Created attachment 175276 [details]
margins problem

tested on https://bugzilla.mozilla.org/attachment.cgi?id=153561
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;
}
(Assignee)

Comment 99

13 years ago
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.
Attachment #174215 - Flags: review-
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

13 years ago
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

13 years ago
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

13 years ago
(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.
*** Bug 292885 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Alias: NoOverflowScroll
(Assignee)

Updated

12 years ago
Alias: NoOverflowScroll

Comment 105

12 years ago
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

12 years ago
(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

12 years ago
(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

12 years ago
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.
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.
(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

12 years ago
(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. 

Updated

12 years ago
Blocks: 318116
(Assignee)

Comment 112

12 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago12 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

12 years ago
No longer blocks: 96394, 137995, 154625, 202386, 240501, 318116

Comment 113

12 years ago
(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?
(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

12 years ago
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.
(Assignee)

Comment 116

12 years ago
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.
(Assignee)

Comment 117

12 years ago
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

12 years ago
(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 ?
(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

12 years ago
> 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

12 years ago
> ... 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

12 years ago
(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.)

Updated

11 years ago
Blocks: 285718
(Assignee)

Comment 123

11 years ago
*** Bug 340270 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

9 years ago
Duplicate of this bug: 452407
Duplicate of this bug: 585676
Duplicate of this bug: 770109

Updated

5 years ago
Duplicate of this bug: 801077
Duplicate of this bug: 962501

Comment 129

3 years ago
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 ?
(Assignee)

Updated

2 years ago
Duplicate of this bug: 396604
You need to log in before you can comment on or make changes to this bug.