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>

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.

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.

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. :-)

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...

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?

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

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

[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... ;-)

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. :-)

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

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

Verified LATER

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...

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

LATER is deprecated per bug 35839.

->default

Reconfirmed using FizzillaCFM/2002070913. Setting All/All.

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

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

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

Taking bug, P1/Future.

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

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

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

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

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

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

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

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

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

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.

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. ***

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

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.

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

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

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

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?

no scrollbar for menu frame on the left

full screen view shows complete menu frame

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 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.

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.

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.

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! :-)

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. ***

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

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

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

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

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.

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).

> 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.)

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.

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. ***

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.

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

*** 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. ***

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'.

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

>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.

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 )

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

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

(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?

(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.

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.

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.

(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.

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

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. ***

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.

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).

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 on attachment 89111 [details] testcase As per Asaf and David's comments #83,#84, marking the first testcase obsolete.

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

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).

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. ***

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.

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

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!

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.

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.

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 .

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

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 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.

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"?

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.

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.

(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. ***

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.

(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.

(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.

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?

(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.

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.

(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?

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.

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.

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.

(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...

> 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?

> ... 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.

(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.)

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

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 ?