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

Status: VERIFIED FIXED

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

Description

[cpratt]

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.

Comment 1

[karnaze (gone)]

Reassigning to Don.

Comment 2

[dcone (gone)]

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.

Comment 3

[dcone (gone)]

*** Bug 12504 has been marked as a duplicate of this bug. ***

Comment 4

[joki (gone)]

Leaving as blocker, moving to M12

Comment 5

[joki (gone)]

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.

Comment 6

[Paul MacQuiddy]

Sorry for the spam, changing QA contact on printing bugs to our new printing
tester, Shrirang!

Comment 7

[rpotts (gone)]

I'm reassinging this to travis since it requires new functionality in the
WebShell...

Comment 8

[travis]

Flipping to Saari he will provide a way to get the currently focussed webShell
or rather DocShell.  He will then flip it to dcone...

Comment 9

[Peter Trudelle]

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.

Comment 10

[rickg]

Moving to m13 -- have a nice day.

Comment 11

[dcone (gone)]

Waiting on the Webshell changes then.. or docshell

Comment 12

[dcone (gone)]

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..

Comment 13

[Peter Trudelle]

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.

Comment 14

[dcone (gone)]

Can I get this API somehow.  Thanks..

Comment 15

[travis]

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.

Comment 16

[travis]

Flipping to dcone until I get an answer from my question.  I don't think this
API or bug lives on the docshell side.

Comment 17

[dcone (gone)]

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.

Comment 18

[travis]

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?

Comment 19

[travis]

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.

Comment 20

[Joseph Elwell]

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

Comment 21

[Peter Trudelle]

cc'ing dcone (instead of me!)

Comment 22

[shrirang khanzode]

*** Bug 25956 has been marked as a duplicate of this bug. ***

Comment 23

[chris hofmann]

beta whiteboard status -> beta1 keyword

Comment 24

[Phil Peterson]

PDT-

Comment 25

[don]

Move to M15 ...

Comment 26

[Ian Zink]

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!

Comment 27

[Lothar Seiffert]

Moving to M13 .. M14 .. M15 ...
Ignorance, arrogance against customer, incompetence?
MSIE don't have this problem since 4.0. 

Comment 28

[travis]

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.

Comment 29

[dcone (gone)]

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. 

Comment 30

[Adam]

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!

Comment 31

[travis]

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.

Comment 32

[shrirang khanzode]

*** Bug 34856 has been marked as a duplicate of this bug. ***

Comment 33

[gehlhaar]

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 :)

Comment 34

[Andreas Franke (gone)]

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...

Comment 35

[Joseph Elwell]

courageously I step forward to add beta2 and wipe the PDT- status as it only 
applied to beta1, which is done and gone.

Comment 36

[Adam]

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)?

Comment 37

[dcone (gone)]

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

Comment 38

[leger]

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.

Comment 39

[dcone (gone)]

This is either Me or Hyatt.. reassigning to myself until I know more.

Comment 40

[dcone (gone)]

Don M. needs to assign to the proper person. 

Comment 41

[don]

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.

Comment 42

[dcone (gone)]

OK,  any printout of a FrameSet will print All of the Frames..

Comment 43

[kenneth buttler]

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.

Comment 44

[verah (gone)]

Nav triage team: reassigning to McAfee

Comment 45

[verah (gone)]

Nav triage team: [nsbeta3+]

Comment 46

[Phil Peterson]

PDT downgrading to P3. Would be nice, but not really hurting anyone.

Comment 47

[verah (gone)]

Nav triage team: nsbeta3-

Comment 48

[dcone (gone)]

*** Bug 55128 has been marked as a duplicate of this bug. ***

Comment 49

[Tobias Burnus]

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?

Comment 50

[shrirang khanzode]

*** Bug 57171 has been marked as a duplicate of this bug. ***

Comment 51

[Kathleen :Brade]

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...

Comment 52

[Gervase Markham [:gerv]]

Fairly sure this is relnoted elsewhere, but anyway...

Gerv

Comment 53

[Michael Ratanapintha]

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.)  

Comment 54

[Boris Zbarsky [:bzbarsky]]

*** Bug 59486 has been marked as a duplicate of this bug. ***

Comment 55

[Boris Zbarsky [:bzbarsky]]

*** Bug 60157 has been marked as a duplicate of this bug. ***

Comment 56

[Ian Zink]

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

Comment 57

[Chris McAfee]

clearing milestone.  yes we need to fix this.

Comment 58

[verah (gone)]

Removing myself from list of cc's.

Comment 59

[Blake Ross]

major complaint of 6.0; this should be addressed for beta1.

Comment 60

[rods (gone)]

This is a dup of one of dcone's bugs as far as I can tell.

Comment 61

[cpratt]

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?

Comment 62

[shrirang khanzode]

spam : changing qa to sujay (new qa contact for Printing)

Comment 63

[Chris McAfee]

.9
This bug sucks, I had other bugs on my list.
We Really Need this fixed.

Comment 64

[Deven Corzine]

Does anyone know what's causing this bug, or is it a complete mystery right now?

Comment 65

[dcone (gone)]

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.

Comment 66

[Chris McAfee]

xpapps asks this to be marked dogfood, adding dogfood keyword.
Thanks don for looking at this.

Comment 67

[dcone (gone)]

Another problem here..is that Iframes will also print on seperate pages.. and 
leave holes in the main page. 

Comment 68

[Gilles Doyen]

Just adding myself to this thread, since I'm having this problem as well. Thank
you!  GD

Comment 69

[Kevin McCluskey (gone)]

Reassigning to Rod, since he is working on the fix and will be checking it in
later next week.

Comment 70

[Asa Dotzler [:asa]]

Who are you getting for SR on this one?  It sounds like it's ready except for
that final step.

Comment 71

[rods (gone)]

Attachment: patch

Comment 72

[rods (gone)]

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

Comment 73

[rods (gone)]

Attachment: Lastest improved patch

Comment 74

[rods (gone)]

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

Comment 75

[sujay]

verified.

Comment 76

[Dave Conley]

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.