left edge cut off; scrolling doesn't handle negative positions?

RESOLVED DUPLICATE of bug 6976

Status

()

Core
Layout
RESOLVED DUPLICATE of bug 6976
5 years ago
4 years ago

People

(Reporter: Daniel B., Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 670925 [details]
screen-shot (well, "window-shot") showing symptoms

If you go to 
http://dev.opera.com/articles/view/1-introduction-to-the-web-standards-cur/ 
and narrow the window enough for page to suppress its Author/Date/etc. box,
then the left of the text gets cut off.  SeaMonkey's scrollbar remains 
at its leftmost position. 

You can't scroll left to see the cut-off content.


It appears that SeaMonkey might be failing to consider negative X 
positions when calibrating the horizontal scrollbar (mapping the range 
of movement of the scrollbar to the range of X positions of content
on the page).

(The leftmost scrollbar position should correspond not to having the
X coordinate of _zero_ at the left edge of the viewport, but to having 
the _lowest_ X coordinate (i.e., possibly a negative value) at the left 
edge of the viewport.)

Comment 1

5 years ago
Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/19.0 Firefox/19.0 SeaMonkey/2.16a1
Build identifier: 20121012003006

Displays the same (wrongly) in Composer, in SeaMonkey, & in FF.
(But of course, it's an Opera web page ;-).)

http://validator.w3.org/check?uri=http%3A%2F%2Fdev.opera.com%2Farticles%2Fview%2F1-introduction-to-the-web-standards-cur%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

Updated

5 years ago
Status: UNCONFIRMED → NEW
Component: Composer → DOM
Ever confirmed: true
OS: Windows 7 → All
Product: SeaMonkey → Core
Hardware: x86_64 → All
Version: SeaMonkey 2.11 Branch → Trunk
This is purposeful: lots of sites depend on this behavior (e.g. by positioning content they don't want to be visible at -10000px or some such).

We do allow scrolling to the left when the body or html is RTL.
Component: DOM → Layout
Whiteboard: DUPEME

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 6976
(Reporter)

Comment 4

5 years ago
(In reply to Mats Palmgren [:mats] from comment #3)
> 
> *** This bug has been marked as a duplicate of bug 6976 ***

.. and that bug has been marked as WONTFIX -- in 2005!

So ...

1.  How the heck are we supposed to use SeaMonkey to view web pages whose
    content coordinates go a bit into negative x-axis territory?  There
    are an increasing number that go negative (e.g., because of centering  
    moderately (or worse) wide content) and thus don't display visibly in 
    SeaMonkey, and do display visibly in some other browser (IE, I think).

2.  Why was this new report dismissed without any review of the seven-year-old
    decision involved in the bug report of which this was marked as a duplicate?
    Things have changed a lot in seven years.  The decision should be evaluated
    anew.

Daniel
The URL works fine for me, in Firefox 16 and Nightly, and SeaMonkey 2.13.2
2.16a1 all on Linux64.

As for bug 6976, that's not going to change - all browsers do this and
it's in the CSS spec.  That said, I'm not entirely sure that the content
was styled with a negative position in this case.

Can you reproduce the problem using a fresh profile?
(Start from command line with "seamonkey -P" then "Manage profiles..."
"Create profile".)
> 1.  How the heck are we supposed to use SeaMonkey to view web pages whose
>    content coordinates go a bit into negative x-axis territory?

One "simple" method is to create an extension that will simply translate such content to the right so it fits in the viewport.  I agree that it's a pain in the centering wide content case, and I do run into that case a fair bit....

> 2.  Why was this new report dismissed without any review

What makes you think there was no review?  I definitely double-checked that changing the behavior here would break all sorts of web sites when I made comment 2.  The fact is, between the CSS spec requiring it and all browsers doing it, lots of web developers "hide" content by positioning it off the start (left, in ltr) edge of the viewport.  If we suddenly allowed scrolling to it you'd have some pretty interesting scrollbars on all sorts of websites...

Updated

4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.