Closed Bug 145176 Opened 22 years ago Closed 22 years ago

Printing triggers "download" of "printProgress.xul"

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
x86
Windows ME
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: neilr+mozilla_bugzilla, Assigned: rods)

References

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0+) Gecko/20020516
BuildID:    2002051608

When printing web pages, a white full-screen window appears that has only the
"Close" icon (not the "Minimize" or "Maximize" icons).  In front of that appears
a standard "Choose what to do with this file (open/save)" dialog box.  (The
"Print Progress" window that would appear when using builds from last week does
not appear, but I don't know if that was an intentional design change or a
side-effect of this bug.)

I normally just wait, and the page prints, at which point I hit "Cancel" on the
open/save window.

On one occasion, this behavior was followed by a crash (Talkback ID: #TB6113913Q).

This bug has appeared in "nightly" builds for approximately a week.  Although I
have not been keeping track of prints-vs-bug-manifestation, my "feeling" is that
it has been manifesting more frequently with each "nightly" build.

Reproducible: Sometimes
Steps to Reproduce:
1. Print a web page.


Actual Results:  A white full-screen window appears that has only the "Close"
icon (not the "Minimize" or "Maximize" icons).  In front of that appears a
standard "Choose what to do with this file (open/save)" dialog box.  Moments
later (without clicking on anything), the page starts printing.

The "Print Progress" bar does not appear.

Expected Results:  Print the web page (and display the "Print Progress" window?)

On one occasion, this bug was followed by a crash, reported as Talkback ID:
TB6113913Q.  So far, however, it has only crashed 1 out of (6-8) times that the
bug manifested.
Try deleting your components.reg file where you execute mozilla and re-run.
Neil, follow rods suggestions and then update the bug...thanks...
Instructed to "update the bug".
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Neil, did deleting the reg file solve the problem?
Oops, never mind.
Oops: I goofed (I misinterpreted the last comment to read "This is a non-issue,
close it."  Sorry for the confusion.)

After deleting the components.reg file, the "open/save" dialog bog still opens,
but now instead of opening a full-screen white window with only a "X" button
("Close") it opens a tiny window that basically consists of the title bar and
the "X" button.

For a few minutes, some of the fonts on the Bugzilla pages were different than
anywhere else on the page, but that seems to have gone away.  (Example: "bug
pages" in the table at the bottom would be a different font than the text
"mozilla.org's" right next to it.)  I've opened and closed Mozilla since
deleting that file, so I'm assuming (the font issue) corrected itself when I did so.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Bug occurred, followed by another crash.

TalkBack ID: TB6407590W.
Mozilla ID: 2002051608.
URL: http://www.techreview.com/articles/print_version/scigliano0602.asp
Bug manifests (on occasion) in build 2002051808.

I uninstalled the previous build (and remembered to manually delete the
remainder of the install directory) and installed a new build.  I was able to
print Page 1 of this bug report without any problems (although the "Print
Progress" window never appeared--was it removed, or should I be seeing it?).

However, when I went to http://www.kevinandkell.com/ and tried to print Page 1,
in addition to the white, full-screen window with only a "Close" button and the
window saying that I had "Chosen to download a file of type: 'XML-Based User
Interface Language' [mozilla.application/cached-xul] from
chrome://global/content/", this time I also got a "Printer Error" window, saying
"Printing failed when completing the document."

This happened twice.  I restarted Windows, and it happened again, but the window
that appeared was the "tiny" window that was so small it was basically just a
title bar with a "Close" button.
After many weeks without seeing it (any many prints), the bug just manifest
itself again in Build 2002062704.  The download window appeared with the white,
full-screen window, and had to be closed by clicking on the "X" after I
"Canceled" (sp) the "download" (but it printed with no problems.)
Bug just occurred followed by a crash (talkback-ID #TB7985330Q).  It still
printed the document, although I asked for a black-and-white version and it
printed in color.

Using Build #2002070108.

When I update Mozilla, I use the Windows uninstaller, then go in and delete the
Mozilla directory that remains.  Then I re-install.  My profile is stored in a
separate directory, so it remains intact between installs.  Could there be
something I'm forgetting to remove between installs?
Was able to reproduce this fairly easily under win98 and w2k on builds from
earlier this week (prints once fine, any future attempt to print will display
the "download a file of type: 'XML-Based User
Interface Language' [mozilla.application/cached-xul] from
chrome://global/content/" dialog box until Mozilla was exited and restarted. 
There was one crash which I don't have the talkback ID for.

But today's build (20020712) has worked as expected - the print progress dialog
box always displays (even if clipped on the right) and goes away without any fuss.
*** Bug 158165 has been marked as a duplicate of this bug. ***
This is almost certainly related to bug #121057, but after looking through
printProgress.xul, I can't find any of the referenced files to be missing.
Also, it seems to only happen with the classic skin.
Anybody seen this on the branch?
I haven't seen this happen for more than a month - recommend WFM if no one objects.
Pardon my ignorance, but should it be "WFM" or "Fixed"?  (The help page for
"Status" says that "WFM" means:

  "All attempts at reproducing this bug were futile, reading the code produces
no clues as to why this behavior would occur. If more information appears later,
please re-assign the bug, for now, file it."

  Since at least 3 other people were able to duplicate the bug (rcummins said it
was easy to do in comment #11), it seems to me that the first test,
non-reproducability, fails, and it should not be WFM'ed.  (If I'm mistaken, feel
free to just ignore me.  :-)
"Fixed" requires that a patch actually be submitted for this bug, and that patch
must actually fix the problem.  "All attempts at reproducing this bug [are now]
futile", so I'll mark it WFM.  If the problem reappears, we'll know which bug to
reopen :-)
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.