Steps to reproduce: 1. Load testcase 2. Select "ab" 3. Print selection EXPECTED RESULTS: - At the very least, the text "ab" should be visible - We should probably show the absolutely-positioned div with "xxx" in it somewhere, too. (perhaps "ab" should move down to make room for it) ACTUAL RESULTS: - Blank page -- no headers/footers -- with this assertion: ###!!! ASSERTION: Selection end point should be after start point: 'endRect.y >= startRect.y', file mozilla/layout/printing/nsPrintEngine.cpp, line 2219 Testing using Firefox 3rc1 on Ubuntu Linux 8.04. Note: Firefox 18.104.22.168 prints a blank page, as well, so this isn't a regression. (Though the assertion was added recently, so that assertion failure won't be printed in Firefox 2.)
(Note: This is not the same as bug 431308, "Print Selection gives blank output within 'position: absolute' div", though their titles sound somewhat similar)
See also bug 436041, which is where I reduced this bug's testcase from. See also bug 436181, which is similar to this bug, but uses relative instead of absolute positioning.
Created attachment 362832 [details] [diff] [review] fix v2: use tightest bound that contains all of both startRect and endRect This new patch is probably a better fix for this. It greatly simplifies all the startRect / endRect edge-case-checking. Basically, the current code assumes that startRect begins & ends before endRect, but that's not necessarily a safe assumption when there's absolutely-positioned content, as this bug shows. This new patch drops the aforementioned assumption -- it simply declares the selection region to be the tightest bound around startRect and endRect, regardless of which one begins first & which one ends last. Note that there's a functional difference between this patch and the previous patch. Using the STR from comment 0, the old patch put "ab" at the top of the page's content area, with "xxx" positioned out of view (off the top of the page). However, this new patch positions "xxx" at the top of the page's content area, with "ab" a little ways below it.
(In reply to comment #5) > Basically, the current code assumes that startRect begins & ends before > endRect, but that's not necessarily a safe assumption when there's > absolutely-positioned content, as this bug shows. Though maybe that *should* be a safe assumption -- i.e. maybe "GetPageRangeForSelection" *should* be giving us rects that satisfy that, even though it's not right now. In that case, the fix would need to be in the GetPageRangeForSelection implementation.