345415 - SeaMonkey Browser: Google Groups article body pushed below right column ads stack lowest point

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Kent Paul Dolan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060711 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060711 SeaMonkey/1.5a

This bug was tested with a clean profile, and the
behavior was identical.

Searching for "Google Groups", the only place I've
seen this bug, didn't find a duplicate. [May I mention
that if the Bugzilla search were ANDed instead of ORed
over the search words, a lot more bug reporters would
be successful at finding duplicate bugs? As it is, far
too many hits are returned to make reviewing them much
fun.]

This is more or less a "reversion", SeaMonkey used
to do this display correctly, now does not, while
Internet Explorer still does it correctly, lessening
the chance that the problem is on the Google Groups
end in their emitted HTML code.

This is a problem with the display of news articles
for groups.google.com, "Google Groups".

Normally (this can be overridden), the Google Groups
dynamically built page is divided horizontally into
two frames, the left a control frame, the right a
"payload" frame of news articles and google ads.
Each frame, as necessary, may have a vertical and/or
horizontal scrollbar

For any Google Groups Usenet News article display
(see example URL, which demonstrated this bug when
opened using a newly launched SeaMonkey browser and
a clean profile), the norm is that ten (or fewer)
articles at a time are displayed one above another
as the "payload" of the display in a scrolled window
for the user, with usually a display ten or more
screenfulls high in the scrolled portion.

Normally the top one of those articles is displayed
as the left of two columns in the right frame. To
its right some "google ads" are displayed. To its
left there is also a "left sidebar" control area, in
the separate frame described above.

Before this bug arose, the article body sat in its
frame at the same height as the right column "google
ads" text.

Now the article body column text area is replaced by
a grey box extending down to the base of the right
column's stack of ads, and the news article body is
displayed below that.

Since the stack of ads is usually the full available
height of the browser window, the immediate (false)
impression to the user is that the news article text
has "gone missing". In fact it is still present, but
the user must scroll down to see it, not an
intuitively obvious requirement.

Despite that scrolling down is an immediate
workaround, it isn't an obvious one. The user is
left with the impression that the browser display
has failed entirely, so I'm ranking this as a "Major
Failure" bug.

Maintainers' mileage on that ranking may vary, of
course.

xanthian.


Reproducible: Always

Steps to Reproduce:
1. Open the example URL with the same nightly build and environment.
2. Observe the failure.
3.

Actual Results:  
Article body is out of sight in the frame, starting
below the bottom of the screen.

Expected Results:  
Article body and "google ads" are displayed
side by side starting at the top of the frame,
as before this bug arose.


This bug may or may not be display size dependent.
My display is set at 1280x800.

Comment 1

[Frank Wein [:mcsmurf]]

Do you still see this bug? I remember Google Groups had a small CSS/HTML problem there in the last two days which is now fixed. If it is not fixed, could you possibly attach a screenshot?

Comment 2

[Kent Paul Dolan]

(In reply to comment #1)
> Do you still see this bug? I remember Google Groups had a small CSS/HTML
> problem there in the last two days which is now fixed. If it is not fixed,
> could you possibly attach a screenshot?

Seems to work for me now too. Interesting. I wonder how they managed
to break it in SeaMonkey while keeping it working in I.E.? That's the
only reason I bothered posting this bug report at all. I guess I know
which browser [e-mail] does QA against.

Marking bug WFM, if this interface will allow that.

xanthian.