Closed Bug 111255 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: jdv, Assigned: attinasi_layout)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [bae:20011127])

Attachments

(2 files)

Testcase based on URL - ver very strange.
276 bytes, text/html
Details
Patch to make the image not split when it is not in paginated mode
891 bytes, patch
karnaze
: review+
Details | Diff | Splinter Review
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
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.
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.
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
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
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
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
Patch attached, gathering reviews...
Summary: Adjacent images flow oddly, appears to split images → [PATCH] Adjacent images flow oddly, appears to split images
I'd leave the test against NS_UNCONSTRAINED_SIZE in -- makes that case clear. Otherwise, this looks fine. sr=waterson
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+
Hmm. Check for IsPaginated and NS_UNCONSTRAINED_SIZE != aReflowState.availableHeight? OK, if that makes it clearer I see no problem with that.
I'll check in a modified testcase too (using local images)
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
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 119615 has been marked as a duplicate of this bug. ***
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: