Closed Bug 139723 Opened 22 years ago Closed 5 years ago

image +   + text does wrap

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

RESOLVED INVALID
Future

People

(Reporter: 3.14, Unassigned)

References

(Depends on 1 open bug, )

Details

(Whiteboard: DUPEME)

Attachments

(3 files, 5 obsolete files)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020419

Go to http://www.heise.de/tp/deutsch/special/copy/12393/1.html. Find some links
with the box-with-arrow symbol infront. If you look at the source you find an
image followed by   and text. If you play with your window width you can
make the image and the text next to it wrap. Then the image is on the end of one
line and a space with the link text on the next line. It should be on the same line.

I don't think, this is bug 42495. Dupe me if I'm wrong.

pi
It's definitely a dupe, but not of 42495...
Whiteboard: DUPEME
*** Bug 139803 has been marked as a duplicate of this bug. ***
Priority: -- → P3
Target Milestone: --- → Future
Changing QA Contact
QA Contact: petersen → moied
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/2002080104

Also happening with Windows -> OS=ALL

pi
OS: Linux → All
Hardware: PC → All
This bug also is present even without nbsp.

Take the following file, where link_up.gif is a small image at the height of one
line. The example should be self-explanatory. I add this here and not as a new
bug, because I think it's the same.

<html>
  <head>
    <title>Wrap Error</title>
  </head>
  <body>
    <p>This is a text to show that the wrapping in Mozilla has a <img
    src="link_up.gif">slight error. It should not separate image from
    the word <em>slight</em>.</p>

    <p>This is a text to show that the wrapping in Mozilla has a <img
    src="link_up.gif"> slight error. It may separate image from
    the word <em>slight</em> here.</p>

    <p>This is a text to show that the wrapping in Mozilla has a<img
    src="link_up.gif"> slight error. It should not separate image from
    the word <em>a</em>.</p>
  </body>
</html>
Attached patch patch (obsolete) — Splinter Review
A patch calculates aMaxElementWidth of consecutive images and text, and breaks
a line including images.
Attached file testcase for a patch (obsolete) —
Attached file testcase for a patch
Attachment #132302 - Attachment is obsolete: true
Attached image a result of a patch (obsolete) —
Attached patch patch (obsolete) — Splinter Review
Attachment #132301 - Attachment is obsolete: true
The other figures same as an image can be also arranged with text by the text
layout code, if the patch is extended.
Attached patch patch (obsolete) — Splinter Review
The patch was corrected because the position of a text was being arranged to
the top.
Attachment #132304 - Attachment is obsolete: true
Attachment #132570 - Attachment is obsolete: true
Attached image screen shot
Attached patch patchSplinter Review
The change for nsLineLayout::FindNextText() was modified.
Attachment #132974 - Attachment is obsolete: true
*** Bug 231609 has been marked as a duplicate of this bug. ***
Isn't this a special case of bug 172819? If nothing except normal space will act
as a line break after image, &nbsp; won't act too, no?
Depends on: 172819
Blocks: 265974
Assignee: attinasi → nobody
QA Contact: moied → layout

The CSS Text spec says that:

The line breaking behavior of a replaced element or other atomic inline is equivalent to an ideographic character (Unicode linebreaking class ID [UAX14]), and additionally, for Web-compatibility, introduces a soft wrap opportunity between itself and any adjacent U+00A0 NO-BREAK SPACE character.

So according to the spec requirement "for Web-compatibility", it's correct that is a soft wrap opportunity there.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: