Closed Bug 384792 Opened 17 years ago Closed 15 years ago

Inline images no longer split when printing

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: bzbarsky, Unassigned)

References

()

Details

(Keywords: regression)

See bug 254659 comment 9.  Testcase is in the URL field.

It looks like line layout always reflows "inline" frames with an unconstrainted vertical height, including images in a line.  I _think_ this is a regression...
Flags: blocking1.9?
Really? I don't think we've ever had the ability to break inline frames vertically. I don't think that fits into our pagination model at all... if an inline image did return incomplete, we would wrap the pieces and give them independent x offsets, which is NOT what you want.
Hmm.  Maybe I'm confused... let me test.
So this changed with bug 297537.  I guess we broke horizontally before that, line-wrapped the second half if the image was wide enough (which in all the testcases it appears to have been), and then the image frame painted the right thing in, huh?
Sad, but understandable.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: blocking1.9?
Resolution: --- → WONTFIX
Can we please re-open this bug as it's a long wanted feature and a flaw. Even IE does this.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reopened at request of Tobbi on livechat. As stated in comment #6 IE8 now does this.
This is wontfix as filed (which is to create continuation frames, etc).

If you want to file a generic bug about doing something sane with too-tall inline images when printing, fine.  But don't hijack other bugs.
Status: REOPENED → RESOLVED
Closed: 17 years ago15 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.