Last Comment Bug 743599 - absolutely positioned element at start of relatively-positioned inline doesn't wrap to next line with the first word of that inline
: absolutely positioned element at start of relatively-positioned inline doesn'...
Status: NEW
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: unspecified
: All All
-- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
: 1280857 1289700 (view as bug list)
Depends on: 389587 489100
Blocks: 489207
  Show dependency treegraph
Reported: 2012-04-08 17:27 PDT by Louis Lazaris
Modified: 2016-11-07 23:01 PST (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

reporter's testcase (1.24 KB, text/html)
2012-04-08 18:23 PDT, David Baron :dbaron: ⌚️UTC-8
no flags Details

Description User image Louis Lazaris 2012-04-08 17:27:40 PDT
When absolutely positioning a pseudo-element inside of an inline element that starts a new line, the pseudo-element is incorrectly positioned at the end of the previous line.

This happens inside a flow of inline text, where the inline element (such as an anchor or span) resides.

This seems to be an undesired behavior because all other modern browsers (latest Chrome, Opera, IE10 PP2) position the pseudo-element differently from Firefox 11.

Here is a JSBin that demonstrates this:,live

Hover over the link to see the pseudo-element.
Comment 1 User image David Baron :dbaron: ⌚️UTC-8 2012-04-08 18:23:50 PDT
Created attachment 613214 [details]
reporter's testcase

(JSBin really doesn't count as a simplified testcase)
Comment 2 User image Boris Zbarsky [:bz] (still a bit busy) 2012-04-09 06:17:01 PDT
The line-break is happening inside the <a>, not before it (in terms of our resulting box tree).  You can see this pretty clearly if you put a 1px left border on the <a>.

So the containing block for the abspos element ends up being the empty inline box before the line-break (see bug 489100).

That seems to be all that's going on here; in particular, this is not related to pseudo-elements in any way; a normal child element would do the same thing.

I don't know offhand whether other browsers put the linebreak in a different place or whether they don't suffer from bug 489100.
Comment 3 User image Louis Lazaris 2012-04-09 11:11:30 PDT
Latest stable Chrome and Safari put the left border on the new line, and the child element is positioned as desired. IE10 PP2 is the same.

Latest stable Opera, however, will work as originally expected with no border, but when you add the border, it behaves the same way as Firefox.

In my opinion, it seems nonsensical for the content to be on a new line while the left border is on the previous line. This doesn't happen if I throw a "br" tag in before the parent element, so why should it happen if the line break is automatically inserted?

But hey, what do I know? :)
Comment 4 User image Boris Zbarsky [:bz] (still a bit busy) 2012-04-09 11:14:26 PDT
The linebreak behavior is a bit silly, imo, yes.  The issue is that we start the parent element, then discover the kid won't fit and break before the non-fitting kid... but part of the parent did fit, so stays on the previous line.  I agree that checking for empty boxes there and not creating them would be nice; that's what Opera seems to be doing based on your description.
Comment 5 User image David Baron :dbaron: ⌚️UTC-8 2012-04-09 11:48:31 PDT
(Related to, but not duplicate of, bug 389587.)
Comment 6 User image Boris Zbarsky [:bz] (still a bit busy) 2012-04-09 11:57:47 PDT
Well, fixing that would fix this bug too, yes.
Comment 7 User image David Baron :dbaron: ⌚️UTC-8 2016-06-22 09:37:51 PDT
*** Bug 1280857 has been marked as a duplicate of this bug. ***
Comment 8 User image David Baron :dbaron: ⌚️UTC-8 2016-11-07 23:00:06 PST
*** Bug 1289700 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.