Open
Bug 67296
Opened 24 years ago
Updated 2 years ago
[FIX]Printing selection: borders outside selection are printed
Categories
(Core :: Printing: Output, defect, P3)
Tracking
()
REOPENED
Future
People
(Reporter: burnus, Unassigned)
References
()
Details
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
This is 2001-01-31-21/Linux Goto the URL and mark e.g. the first line. All links which use "border-bottom:" are printed (dotted and dashed lines all over the page). Moreover: If I only select one word of the <h1> title on that page, I get a huge blue frame (of the multiline <h1>) and all other frame backgrounds print too. (This is the print to ps output, not X11/Xprt)
Comment 1•24 years ago
|
||
This is for you Rod
Assignee: dcone → rods
Summary: Printing selection: borders outside selection are printed → Printing selection: borders outside selection are printed
Updated•24 years ago
|
Summary: Printing selection: borders outside selection are printed → [MF]Printing selection: borders outside selection are printed
Target Milestone: --- → mozilla0.9
Comment 3•24 years ago
|
||
Comment 4•24 years ago
|
||
Comment 5•24 years ago
|
||
Some comments: nsBlockFrame::IsVisibleForPainting - the if(aCheckVis) block needs to set aIsVisible when TRUE too, like maybe '*aIsVisible = disp->IsVisible(); return NS_OK;' Same thing in nsFrame version, actually, since that block is identical in both (that block could be factored, but whatever, not really worth it). Personally, I'd prefer if GetSelectionforVisCheck returned an nsresult and had an inout param for the nsISelection* - then you could propagate the error from selcon->GetSelection (assuming that there is one, otherwise that API is probably masking the error and it should be commented as such). And the 'for' shoudld probably be capitalized, as in GetSelectionForVisCheck(...). Meditate on those comments and you get the coveted 'sr=attinasi', grasshopper.
Comment 7•24 years ago
|
||
Setting milestone to mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.8.1
Comment 8•24 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 9•24 years ago
|
||
With Mozilla 0.9 I still get the effect that I get dotted borders with the URL file. (Those are inline borders of <accr> and <abbr>, <span>; from CSS: border-bottom: 1pt dotted rgb(40%,40%,40%);) Note that those borders are in paragraphs which are *not* selected! (Note further that the border of frames [of <p> etc.] which are only partly selected print full size. It would look better if the frame hight would be as high as if this paragraph (etc.) whouldn't contain more lines.) If needed be I can attach a ps file (or a gif of the ps file or ...)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 11•23 years ago
|
||
The problem is the nsHTMLContainer::Paint needs to do an IsVisibleForPainting but it can't because then nothing gets painted. So it needs to check to see if the frame is a span or whether the content an acronym or abbr. The span approach is far more generic, but I am unsure of all the case where it will kick in. The content specific cases for acronym and abbr works well but might miss some other cases. I have tested both approaches, Approach #1: // check to see if container is an acronym or abbr PRBool isVisible = PR_TRUE; if (mContent) { nsCOMPtr<nsIAtom> tag; mContent->GetTag(*getter_AddRefs(tag)); if (tag.get() == nsHTMLAtoms::acronym || tag.get() == nsHTMLAtoms::abbr) { if (NS_FAILED(IsVisibleForPainting(aPresContext, aRenderingContext, PR_FALSE, &isVisible))) { isVisible = PR_TRUE; } } } Approach #2: // check to see if container is span PRBool isVisible = PR_TRUE; nsCOMPtr<nsIAtom> frameType; GetFrameType(getter_AddRefs(frameType)); if (frameType.get() == nsLayoutAtoms::inlineFrame) { if (NS_FAILED(IsVisibleForPainting(aPresContext, aRenderingContext, PR_FALSE, &isVisible))) { isVisible = PR_TRUE; } }
Status: REOPENED → ASSIGNED
Updated•23 years ago
|
Summary: [MF]Printing selection: borders outside selection are printed → [FIX]Printing selection: borders outside selection are printed
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.1
Updated•23 years ago
|
Priority: -- → P2
Target Milestone: mozilla1.1 → Future
Updated•15 years ago
|
Assignee: rods → nobody
Status: ASSIGNED → NEW
QA Contact: sujay → printing
Comment 14•15 years ago
|
||
Eight years old, duplicating against current bug.
Status: NEW → RESOLVED
Closed: 24 years ago → 15 years ago
Resolution: --- → DUPLICATE
Comment 15•14 years ago
|
||
At least superficially, this doesn't look at all like a dupe of bug 428111, as I noted in bug 428111 comment 7. Un-marking as dupe.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 16•6 years ago
|
||
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•