Print selection prints blank pages, with absolutely-positioned div that's shifted upwards

ASSIGNED
Assigned to

Status

()

Core
Printing: Output
ASSIGNED
10 years ago
5 years ago

People

(Reporter: dholbert, Assigned: dholbert)

Tracking

(Blocks: 1 bug, {assertion, testcase})

Trunk
assertion, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

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 2.0.0.14 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.)
Summary: Print-selection prints blank pages, with absolutely-positioned div that's shifted upwards → Print selection prints blank pages, with absolutely-positioned div that's shifted upwards
Created attachment 322844 [details]
testcase 1
(Note: This is not the same as bug 431308, "Print Selection gives blank output within 'position: absolute' div", though their titles sound somewhat similar)
Blocks: 436041
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 330332 [details] [diff] [review]
fix?

I think this fixes the issue.
Flags: wanted1.9.1?
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
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.
Flags: wanted1.9.1?
Duplicate of this bug: 431308
You need to log in before you can comment on or make changes to this bug.