Closed Bug 7201 Opened 26 years ago Closed 24 years ago

[FIX]When printing pages w/frames, frames print on separate pages [print][frames]

Categories

(Core :: Printing: Output, defect, P1)

Product:
Core
Component:
Printing: Output
Platform:
All
Other
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: cpratt, Assigned: rods)

References

(
URL
)

Details

(Whiteboard: relnote-user)

Attachments

(2 files)

patch
(deleted), patch
Details | Diff | Splinter Review
Lastest improved patch
(deleted), patch
Details | Diff | Splinter Review 
build id: 1999052517
platform: windows 98

to reproduce:
go to the above page, wait for it to load the page with frames, and then print.
result: the left-hand frame prints on a page, is ejected, and the the "main"
frame prints on a separate page.
expected result: the printout matches what you see on the screen.
Assignee: karnaze → dcone
Reassigning to Don.
Status: NEW → ASSIGNED
Target Milestone: M10
Component: HTMLFrames → Printing
Blocks: 11275
Assignee: dcone → joki
Status: ASSIGNED → NEW
I am giving this bug to joki for the first half.
We need a way find the currently selected frameset by asking the webshell if it
is the currently infocus Webshell.  Tom Pixley will implement this.. and when
that is finished return the bug to Don Cone to use this feature and fix the bug.
Blocks: 12504
Summary: when printing pages w/frames, frames print on separate pages → [Blocker]when printing pages w/frames, frames print on separate pages
No longer blocks: 12504
*** Bug 12504 has been marked as a duplicate of this bug. ***
Blocks: 12505
Severity: normal → blocker
Whiteboard: [BETA]
QA Contact: beppe → cpratt
Status: NEW → ASSIGNED
Summary: [Blocker]when printing pages w/frames, frames print on separate pages → [BLOCKER]when printing pages w/frames, frames print on separate pages
Target Milestone: M10 → M12
Leaving as blocker, moving to M12
Assignee: joki → rpotts
Status: ASSIGNED → NEW
So the base issue here is that we need to be able to query webshells to see if
they are in focus.  To my mind this can be accomplished either by having the
webshell keep track of their own focus state or adding a new widget api method
to query focus.  I think the latter is easier.  Unfortunately I don't really
have time to work on this right now and I'm going to be out this week so I'm
going to dump this on rick (sorry rick) as temp-owner of webshell.  Have fun.
Sorry for the spam, changing QA contact on printing bugs to our new printing
tester, Shrirang!
Assignee: rpotts → travis
I'm reassinging this to travis since it requires new functionality in the
WebShell...
Assignee: travis → saari
Flipping to Saari he will provide a way to get the currently focussed webShell
or rather DocShell.  He will then flip it to dcone...
Assignee: saari → dcone
Depends on: 20225
Summary: [BLOCKER]when printing pages w/frames, frames print on separate pages → When printing pages w/frames, frames print on separate pages
No need for all the flipping, this is a dependency relationship.
reassigning to dcone as per travis, adding dependency on 20225, which should be
fixed by GetFocusedEventTarget, which returns a frame you can QI to get the
docshell.
No longer depends on: 20225
Target Milestone: M12 → M13
Moving to m13 -- have a nice day.
Status: NEW → ASSIGNED
Waiting on the Webshell changes then.. or docshell
Assignee: dcone → trudelle
Status: ASSIGNED → NEW
I am giving this to you so you can maybee tell me what should be done.
The bug that you said this depends on is marked fixed.. and it does not solve
this problem.  I need an API in Webshell that will give me the currently
selected Frame in a Frameset.. for printing.  I called Chris S. and he said his
fix does not give me what I need.  When we print a Frameset.. the printing code
has no idea what frame to print of the frameset... This bug went full circle
without a fix..
Assignee: trudelle → dcone
I was just pointing out another bug thought necessary for fixing this, didn't
expect it to actually fix this. If you need a webshell API, please work that out
with Travis. Let's not morph this bug.
Assignee: dcone → travis
Can I get this API somehow.  Thanks..
Why do you need a method on WebShell to know the currently focused frame?  A
webshell is a frame.  What you want is to be able to ask what the currently
focused frame is.  In talking with Saari I thought that is what
GetFocusedEventTarget was supposed to do.  That's why I had handed the bug over
to him as he asked.
Assignee: travis → dcone
Flipping to dcone until I get an answer from my question.  I don't think this
API or bug lives on the docshell side.
Assignee: dcone → travis
Printing needs to know what frame (A frameset frame) not an internal mozilla
frame.. or Webshell(docshell) is in focus.  There is a frame or
Webshell(docshell) that is currently selected or in focus for the document a
user is looking at if it is a frameset.  When we print we have to know what that
is because we are not printing the entire document, just one frame.  I talked
with Saari and he said there is not an API for that request.
I just want to know which webshell(or docshell) is currently in focus.. and
thats the one that will get printed.  Currently I print them all and this is
wrong.
Again I ask, why do you want to ask *webhshell* what the currently focused
frame is?  A webshell is a particular frame.  That's like going to any random
window in the system and asking, what window in the system is currently in
focus.  What you really do is ask a window manager of sorts what current window
is in focus.  So do we not have a facility for asking what the currently
focused object in the system is?  Is this not what GetFocusedEventTarget is?
Whatever this object is can you not walk to the correct webshell or whatever it
is you are wanting?
Target Milestone: M13 → M14
Moving to M14, still haven't gotten an answer to my questions posted.  I was
trying to be nice by not reassigning the bug to get the questions answered.  At
this point I am not considering this my bug until my questions are addressed.  I
will reassign soon if they aren't.
In case anyone didn't know: I'm getting a seperate spool for each frame also. I
tested this on http://www.ph.unimelb.edu.au/~ywong/frames.html Mozilla build
2000011908 winNT build.

Printer Brand: HP
Printer Model & Type: LaserJet 4M Plus
Printer Driver Version: 4.01
cc'ing dcone (instead of me!)
*** Bug 25956 has been marked as a duplicate of this bug. ***
beta whiteboard status -> beta1 keyword
Keywords: beta1
Whiteboard: [BETA]
PDT-
Whiteboard: [PDT-]
Move to M15 ...
Priority: P3 → P2
Target Milestone: M14 → M15
AHHHH! I plead with you move it back to M14. I have been very excited about M14
for sometime, because that was when this supposed to be resolved. I cannot use
mozilla as my primary browser until this printing issue is fixed. Please do not
postpone this bug. Look at the number of votes for the bug. 7201!
Moving to M13 .. M14 .. M15 ...
Ignorance, arrogance against customer, incompetence?
MSIE don't have this problem since 4.0. 
Per comments previously moving back to dcone.  Still haven't heard anything.  
There should be some functionality that makes obtaining the currently focused 
item easy.  All the work Saari and Hyatt did I think provided this 
functionality.
Assignee: travis → dcone
Please.. why can't a webshell find out if it is in focus.  I am traversing all 
the webshells, looking for leaf webshells.. and when I get one I just need to 
know if it is in focus.  Thats all. If it is It will be printed.  If not I will 
continue to traverse them.  Thats it, all, done.  There is no other way to find 
this, Saari has told me this, and Joki and at the Raptor all hands we have 
decided that the Webshell was responsible for this.  If this will not be done 
just say and I will bring it up and get someone to add this interface. It is a 
big blocker.
Assignee: dcone → travis
Wow. This looks like one hell of a bug. Changing Platform to ALL - happens on

Mozilla M15 2000031808 Mac OS 9 (and every other platform). Good luck!
Hardware: PC → All
WebShell shouldn't know about if it is in focus, just like every other widget 
shouldn't know about if it itself is in focus.  There is suppose to be a 
central place to query and find out what is in focus.  This is what I said back 
in December.  Anyway, you can find this access this service with 
document.commandDispatcher.focusedWindow will return an nsIDOMWindow.  From 
there you can QI that to an nsIScriptGlobalObject.  From that you can do a 
GetDocShell to see if that is the docShell you currently have.  Flipping to 
dcone to implement since all the functionality he needs is available.
Assignee: travis → dcone
Status: NEW → ASSIGNED
Target Milestone: M15 → M16
*** Bug 34856 has been marked as a duplicate of this bug. ***
Please please *please* PLEASE make this a "true blocker" for M16.
This is a Bad Bug that needs to be squashed to make Mozilla a
usable app.  The use of frames is becoming increasingly common, and
the inability to print what's on the screen is just plain old
unacceptable.  The discussion on this bug appears to be a series
of pass-the-buck arguments -- not terribly productive.  Just fix it :)

And please recall that there are two different things:
1. print the frame which currently has focus (e.g. demanded in bug 34856)
2. print the complete page (frameset) the way it is as displayed on the screen 
   (this bug)
For the latter, it shouldn't be neccessary to know which frame is in focus, 
as far as I understand. Or do I misunderstand the semantics of "having focus"?

Maybe it would magically help if someone was adding the "beta2" keyword 
and wiping the status whiteboard? I'm not courageous enough to do this...

courageously I step forward to add beta2 and wipe the PDT- status as it only 
applied to beta1, which is done and gone.
Keywords: beta2
Whiteboard: [PDT-]
Might as well summon up that courage one last time to wipe beta1 from the 
keywords field (unless we plan to go back in time to fix bugs before they even 
happen)?

Hyatt -- 
I talked with Travis.. he suggested I do this myself - or have you do this.  
Since you have done this before, its probably better you do this.  He suggested 
that we need a getFocusedElement() off of nsPDomWindow that will get the 
currently in focus DocShell().  This is needed to print the current frame in a 
FrameSet.. and all I have is an nsIDocument.  He said QI this to a Dom Window, 
then to walk up until there is not other parent. Can you help out with this.. 
this is really important. If you can't send it back to me and I will figure this 
out. I just thought you could get this done faster and better than me since you 
are familiar with this area.   Thanx
Assignee: dcone → hyatt
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Removing beta2 keyword since this is a feature for beta2.  If  this is not 
working in last few weeks of beta2 prep, elect for beta2.  But features planned 
do not need a keyword.  See rickg if you have questions.  Moving assignment to 
don per PDT mtg today.
Assignee: hyatt → don
Status: ASSIGNED → NEW
Keywords: beta2
Whiteboard: [PDT-]
This is either Me or Hyatt.. reassigning to myself until I know more.
Assignee: don → dcone
Assignee: dcone → don
Don M. needs to assign to the proper person.
Target Milestone: M16 → Future
Reduced severity to critical.  This isn't blocking anyone as far as I know and
it's certainly off the feature list for Seamonkey.  Also removed beta1 keyword
and PDT- status.
Severity: blocker → critical
Keywords: beta1
Whiteboard: [PDT-]
OK,  any printout of a FrameSet will print All of the Frames..

this bug is stale. it has not been look at in 30 days. i have retested it with
the 2000070508 build on windows NT: this bug still accured as the original report.
Keywords: nsbeta3
Nav triage team: reassigning to McAfee
Assignee: don → mcafee
Nav triage team: [nsbeta3+]
Whiteboard: [nsbeta3+]
Priority: P2 → P1
PDT downgrading to P3. Would be nice, but not really hurting anyone.
Priority: P1 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP3]
Nav triage team: nsbeta3-
Whiteboard: [nsbeta3+][PDTP3] → [nsbeta3-][PDTP3][cut 0919]
*** Bug 55128 has been marked as a duplicate of this bug. ***
Since NS PR 3 is shipping, suggest RTM (or if not happening relnotesRTM).
Moreover mozilla0.6/9 would be an appropiate keyword, wouldn't it?

*** Bug 57171 has been marked as a duplicate of this bug. ***
this is so bad... instead of getting 1 page I'm getting 4(!) for Netcenter's
webmail (top, left, bottom/right, and a page with the borders between the
frames).  We should let our users know that they can expect to use a lot of
paper if they try to print pages with frames...
Keywords: relnoteRTM
Fairly sure this is relnoted elsewhere, but anyway...

Gerv
Whiteboard: [nsbeta3-][PDTP3][cut 0919] → [nsbeta3-][PDTP3][cut 0919] relnote-user
The problem is worse on my computer.  When I use a page at the server 
www.techtv.com, which are heavily loaded with Java and JavaScript for the ads, I 
tried printing one page and got two pages, each with one ad, one empty page and 
nothing else.  I checked the page source and found that each ad was seperated by 
a frame.  (Specifically, the tag used to seperate the ads was </IFRAME>, which 
indicated a frame.)  
*** Bug 59486 has been marked as a duplicate of this bug. ***
*** Bug 60157 has been marked as a duplicate of this bug. ***
For an example on how exactly dreaded this bug is try to print
http://www.intellicast.com/LocalWeather/World/UnitedStates/Central/Missouri/StLouis/Forecast/
Watch in horror as a total of not one.. not two.. not three.... not nine... but
TEN pages print off for a simple weather forecast! This bug in imnsho should be
a Showstopper. I don't know netscape released a 6.0 browser that cannot even
print intellicast.com forecasts. This bug stops me from recommending Mozilla and
NS6 to any of my friends and collugues. Please, Please, PLEASE fix this bug. I
have seen numberous other bugs marked duplicates of this one. It is very
important. People still do print, a lot.I have watched this bug slip since I
think it was milestone 9! Now it marked "Future." Please someone set a mark on
when this bug should be fixed and make it work. *please*


Ian Zink
clearing milestone.  yes we need to fix this.
Target Milestone: Future → ---
Removing myself from list of cc's.
Keywords: mozilla1.0
major complaint of 6.0; this should be addressed for beta1.
Keywords: mozilla1.0, nsbeta3 → mozilla0.9, nsbeta1
Whiteboard: [nsbeta3-][PDTP3][cut 0919] relnote-user → relnote-user
Priority: P3 → P1
Target Milestone: --- → mozilla0.8
This is a dup of one of dcone's bugs as far as I can tell.
Well, I filed this 1 year and 8 months ago, and dcone commented on it as far 
back as August 1999... if it's a duplicate of one of his, do you have the bug 
number?
spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay
.9
This bug sucks, I had other bugs on my list.
We Really Need this fixed.
Target Milestone: mozilla0.8 → mozilla0.9
Does anyone know what's causing this bug, or is it a complete mystery right now?
I am currenlty looking into this bug.  We know exactly what causes it.. 
Does not mean its easy to fix.. the problem is that FrameSets depend on a native 
window with events.. printers dont have native windows with events.
I will take this bug.. this is high on th priority list.
Assignee: mcafee → dcone
xpapps asks this to be marked dogfood, adding dogfood keyword.
Thanks don for looking at this.
Keywords: dogfood
Status: NEW → ASSIGNED
Summary: When printing pages w/frames, frames print on separate pages → When printing pages w/frames, frames print on separate pages [print][frames]
Another problem here..is that Iframes will also print on seperate pages.. and 
leave holes in the main page.
Keywords: dogfood → nsdogfood
Just adding myself to this thread, since I'm having this problem as well. Thank
you!  GD
Blocks: 64841
Reassigning to Rod, since he is working on the fix and will be checking it in
later next week.
Assignee: dcone → rods
Status: ASSIGNED → NEW
Who are you getting for SR on this one?  It sounds like it's ready except for
that final step.
Attached patch patch (deleted) — — Splinter Review 

    
  
Status: NEW → ASSIGNED
Summary: When printing pages w/frames, frames print on separate pages [print][frames] → [FIX]When printing pages w/frames, frames print on separate pages [print][frames]

    
    

    
  
There are still problem with printing this page which I am looking into. One of 
which is an already files bug on printing images.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Lastest improved patch (deleted)
        — 
          — Splinter Review
      

    


  

    
  
Blocks: 75664

    
    

    
  
I am closing this bug because Printing Frames "AsIs" now works. Any bugs related 
to it not working correctly should be filed as new bugs instead of reopening 
this bug.

FIXED
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
  
Blocks: 77421

    
    

    
  
verified.
Status: RESOLVED → VERIFIED

    
    

    
  
Status: NOT FIXED/INCONSISTENT.
Visited 2 different web pages with frames (webtech.com and cbaci.org). 
cbaci.org everything printed perfectly. webtech.com however only printed half 
of the main window and never printed contents of the frame. 


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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: