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.

Reassigning to Don.

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.

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

Leaving as blocker, moving to M12

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!

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

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

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.

Moving to m13 -- have a nice day.

Waiting on the Webshell changes then.. or docshell

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

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.

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.

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

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?

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

PDT-

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

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.

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!

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.

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

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

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.

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

Don M. needs to assign to the proper person.

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.

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.

Nav triage team: reassigning to McAfee

Nav triage team: [nsbeta3+]

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

Nav triage team: nsbeta3-

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

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

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.

Removing myself from list of cc's.

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

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)

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

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.

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

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

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

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

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

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

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

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.