Closed Bug 274424 (mapquest) Opened 20 years ago Closed 19 years ago

Missing pages in print out.

Categories

(Core :: Printing: Output, defect)

1.0 Branch
x86
Windows 2000
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jhihn1, Unassigned)

References

()

Details

(Keywords: dataloss, top100)

Attachments

(5 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

This bug exists for Mozilla 1.7, and Firefox 1.0 (The browser being used to
report this is not the one it occured on. So I think there is a problem in their
common hertitage. 

The printout generated is missing pages. This is quite inconvienit because I was
using mapquest driving directions and got within a few miles to where I was
going, then realized there were no more pages. I had to return home, reprint
(the printer-friendly version) and return. This process took several hours...

Reproducible: Always

Steps to Reproduce:
1. Create a long route (~10 turns) 
2. On the resulting page, click the 'map' link next to each turn, so you can see
the 'turn-by-turn' directions.
3. After expaninding, print.

Actual Results:  
I usually got 3 pages - 
1. 1 page with a mapquest header
2. 1 page with the directions, but only the first few & their maps
3. 1 page of the entire route

Expected Results:  
...
2. SEVERAL pages showing turn-by-turn maps
...
Looks a bit like bug 237374.

(The "Steps to reproduce" above crashes current Mozilla (2004-12-10-06) -
I have spawn this off as a separate bug 274516)
Assignee: general → core.printing
Severity: normal → major
Component: General → Printing
Depends on: 237374
Keywords: top100
Product: Mozilla Application Suite → Core
QA Contact: general
Version: unspecified → 1.0 Branch
*** Bug 295815 has been marked as a duplicate of this bug. ***
Bug 295815 is NOT a dupe of this bug, although it does make this bug worse than
it was when it was originally reported.  This bug exists in the 1.7 and aviary
1.0 branches as well as the trunk, whereas bug 295815 only exists in the trunk.
 In this bug, when you try printing from the standard map view, it prints a page
with the Mapquest logo, the first page of directions, and a page with a map. 
But (in Firefox 1.0.x and Mozilla 1.7.x) you can get around this by using the
printer-friendly map page, which will print the entire set of directions.  In
bug 295815, which only exists in the trunk, the printer friendly view only
prints the first page of directions, and then a blank page.  If you try printing
from the standard map view, then it prints the page with the logo, the first
page of directions, and then a blank page.  So even if bug 295815 is fixed, this
bug still exists (since it will go back to the 1.0.x branch behavior).

Please compare the testcases I attached to bug 295815 to the ones I plan to
attach to this bug...or even better, try for yourself!

1. Go to http://tinyurl.com/8hwl4 (this generates directions from New York, NY
to Boston, MA) using Firefox 1.0.6 or Mozilla 1.7.11.
2. Try printing it (or use print preview).
3. Compare the printed directions to the ones on screen...it should have printed
a page with the Mapquest logo, then a single page of directions, and a page with
a map.  But compare carefully, because those directions only take you halfway to
Boston!
4. Now go to the printer friendly view (http://tinyurl.com/7z3f7) and try
printing it.
5. Notice that the entire set of directions printed.
6. Now repeat the above steps, but this time in a current trunk build of either
Firefox or Seamonkey.
7. For the non-printer friendly view, notice that the third page is now blank
instead of containing the map.  For the printer friendly view, note that it now
only printed the first page of directions followed by a blank page.

As you can see, these bugs are not the same.  They may be related, but this bug
is much older than bug 295815 (which only exists on the trunk)...in fact, this
bug is different on the trunk than it is on the 1.0.x branch due to whatever
caused bug 295815!
This demonstrates the problem as originally reported by the original reporter
of this bug.  Note that the first page has the Mapquest logo, the second page
has the first 15 turns, and the third page has the map.  Note that the
directions (as printed) only take you as far as I-84 in CT, not all the way to
Boston.

http://tinyurl.com/8hwl4 is the testcase used for this testcase, a set of
directions from New York, NY to Boston, MA.  It was printed using Mozilla
1.7.11.
This PDF shows the printout of the printer-friendly view of the same set of
directions using Mozilla 1.7.11.  Note that it does correctly print everything.
Here is the same set of directions printed using the 2005-08-08 trunk build of
Firefox.  Note that it is almost exactly the same as the testcase printed using
Mozilla 1.7.11, except that the third page is now blank instead of having the
map.  This shows that a new issue on the trunk (bug 295815) has changed the
behavior of this bug.
Here is the same set of directions printed on the 2005-08-08 trunk build of
Firefox, but this time with the printer friendly view.	Although that worked
fine in Mozilla 1.7.11, note that using a trunk build it only prints the first
11 turns on the first page, and then has a blank second page and no third page.
 There is now no way to print the whole set of directions without downgrading. 
THIS is what bug 295815 is all about.

Now, I realize that fixing this bug may fix bug 295815 too, since I'm not
familiar with the internal workings of the printing engine.  But bug 295815
seems to be a small piece of this bug, and at least having printer-friendly
view fixed for Firefox 1.5 should be a high priority.  I hope that I at least
made the issues more clear to all parties involved...
Confirming bug.  This has been around for a while, and the only work-around I've
found is to switch to IE and print.  This is horribly annoying.
This bug does not match the behavior for bug 237374, so removing depends.
Alias: mapquest
Status: UNCONFIRMED → NEW
No longer depends on: 237374
Ever confirmed: true
Keywords: dataloss
*** Bug 301885 has been marked as a duplicate of this bug. ***
I re-opened bug 295815 for the regression which happened on 2005-04-29. Once
that bug is fixed, we can see if the original problem reported in this bug still
exists, and act accordingly.
Depends on: 295815
This bug seems to have resolved itself.  I tested printing my testcase
(http://tinyurl.com/8hwl4) on the 2005-10-01 build to see if the fix for bug
295815 fixed this one too, and noticed that it does seem to be fixed.  However,
I then tested it with the 2005-09-30 build, which didn't have the fix from bug
295815 yet, and the bug didn't exist anymore on that build either.  So it seems
that either some other bug fixed this one, or Mapquest changed their website in
such a way that this bug no longer happens.

Also, this bug should be Hardware -> All, OS -> All.
Here is my testcase (http://tinyurl.com/8hwl4) printed on the 2005-10-01
1.8-branch build of Firefox.  Note that all pages seem to be there...compare it
to attachment 192104 [details].
(In reply to comment #11)
> So it seems
> that either some other bug fixed this one, or Mapquest changed their website in
> such a way that this bug no longer happens.

The latter, I'm afraid - since I can't reproduce the original bug even with
Firefox 1.0 (or 0.10.1 - the version it was reported for).
Given that we don't have a record of the original HTML which produced the
problem,  there's no use in keeping this bug report open. Resolving WORKSFORME,
although the problem might still be lurking there, waiting for some HTML to
trigger it.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: