[PATCH] Adjacent images flow oddly, appears to split images

RESOLVED FIXED in mozilla0.9.8

Status

()

Core
Layout
P1
major
RESOLVED FIXED
17 years ago
17 years ago

People

(Reporter: jdv, Assigned: Marc Attinasi)

Tracking

({regression})

Trunk
mozilla0.9.8
x86
All
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bae:20011127], URL)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
Mozilla .0.9.6 appears to flow adjacent images in an interesting way.  If a
couple of images are next to each other, and the first is aligned left, the
second one will flow around it; if the image is larger, it will split along the
middle.  Result is that the two images appear to be 3 images: 2 with the same
height, and a third with the same width as the second, but left-justified and
some white space down.

This "third" image will be on top of any text present after the images.

I noticed this with a page that uses stylesheets to right-justify a header, but
wanted a single button image left-justified within that class.  Well, it works
in Mozilla up to .0.9.5, and in all versions of IE and Opera I test with.

Decomposed the test case to simple HTML (see below).

<html>
<head>
  <title>clevermonkey dot org | mozilla test</title>
  <link rel="creator" href="mailto:jdv@clevermonkey.org" type="text/html">
</head>

<body>

<!-- Header -->
<p>
<img src="images/monkeyglyph.png" alt="[monkey glyph]" align="left">
<img src="images/clevermonkey.png" alt="welcome to clevermonkey dot org">
</p>
<!-- END Header -->

<!-- Main text box, left col fully justified -->
<div>
<p>This is a test of Mozilla 0.9.6.</p>
</div>
<!-- END main text box -->

</body>
</html>
layout.  This is very very broken... 
Assignee: asa → attinasi
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: doronr → petersen

Comment 2

17 years ago
Is http://news.bbc.co.uk/ the same problem?

Note the weird clipping and improper placement of the large images next to the
top stories that sometimes occurrs during incremental reflow.

Comment 3

17 years ago
I believe this is an image problem, if you select to view each image within the 
browser, they are treated as if they are plug ins
http://www.clevermonkey.org/images/monkeyglyph.png
http://www.clevermonkey.org/images/clevermonkey.png

give it a try -- really weird
Assignee: attinasi → pavlov
Component: Layout → ImageLib
QA Contact: petersen → tpreston
beppe, you must be testing this on a Mac and letting QuickTime override
Mozilla's PNG handling...  On Linux those images are _not_ treated as plugins.

Comment 5

17 years ago
beppe: you have quicktime taking over pngs... you probably want to turn that off.

back to attinasi.. something very odd is going on with this.  if you resize the
window smaller, you see them get put together as you would think they should..
not sure whats going on
Assignee: pavlov → attinasi
Component: ImageLib → Layout
OS: Linux → All
QA Contact: tpreston → petersen

Comment 6

17 years ago
how in the world did that happen? sorry

this is a really crazy bug, there isn't any odd code going on or any fancy css.
Priority: -- → P2
Whiteboard: [bae:20011127]
Target Milestone: --- → mozilla0.9.8

Comment 8

17 years ago
Created attachment 64393 [details]
Testcase based on URL - ver very strange.

Comment 9

17 years ago
Not only is this strange, it is very serious.  I think it might be related to
some changes that Karmaze made to allow images to split when printed...
Assignee: attinasi → attinasi_layout
Keywords: regression
Priority: P2 → P1

Comment 10

17 years ago
The image is being split because the available height is NOT unconstrained -
this makes it assume that it is printing, which clearly it is not.  We had an
assumption that a constrained availableHeight would only happen in printing, but
now I see that nsLineLayout::ReflowFrame sets the availHeight like this:

  if (NS_UNCONSTRAINEDSIZE == mBottomEdge) {
    availSize.height = NS_UNCONSTRAINEDSIZE;
  }
  else {
    availSize.height = mBottomEdge - mTopEdge;
  }

Clearly the assumtion was wrong, so I am changing the logic in the ImageFrame to
check for being in paginated mode instead of assuming that a constrained
available height means we must be paginated.  I need to check the block code,
and probably tables too, to make sure we correct that erroneous assumption.
Status: NEW → ASSIGNED

Comment 11

17 years ago
Created attachment 64430 [details] [diff] [review]
Patch to make the image not split when it is not in paginated mode

Comment 12

17 years ago
Patch attached, gathering reviews...
Summary: Adjacent images flow oddly, appears to split images → [PATCH] Adjacent images flow oddly, appears to split images

Comment 13

17 years ago
I'd leave the test against NS_UNCONSTRAINED_SIZE in -- makes that case clear.
Otherwise, this looks fine. sr=waterson

Comment 14

17 years ago
Comment on attachment 64430 [details] [diff] [review]
Patch to make the image not split when it is not in paginated mode

r=karnaze
Attachment #64430 - Flags: review+

Comment 15

17 years ago
Hmm. Check for IsPaginated and NS_UNCONSTRAINED_SIZE !=
aReflowState.availableHeight?  OK, if that makes it clearer I see no problem
with that.

Comment 16

17 years ago
I'll check in a modified testcase too (using local images)

Comment 17

17 years ago
Fix checked in, along with new regression test (block/bugs/111255.html)

/cvsroot/mozilla/layout/html/base/src/nsImageFrame.cpp,v  <--  nsImageFrame.cpp
new revision: 1.223; previous revision: 1.222

Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
*** Bug 119615 has been marked as a duplicate of this bug. ***

Comment 19

17 years ago
*** Bug 119986 has been marked as a duplicate of this bug. ***
*** Bug 109866 has been marked as a duplicate of this bug. ***
*** Bug 110854 has been marked as a duplicate of this bug. ***
*** Bug 121141 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.