Closed Bug 1072991 Opened 5 years ago Closed 5 years ago
.5 .1 print function not working with recently updated versions of Firefox .
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140923175406 Steps to reproduce: 1. Visit www.incord.com 2. Click "PRODUCTS" in top nav bar. 3. Link takes you to http://incord.com/netting_hardware/index.htm. 4. Click a thumbnail - try the first one captioned M250BK. 5. Link works properly, takes you to http://incord.com/images/spec_pages/netting/M250BK_spec.jpg using lightbox for presentation. 6. Click PRINT button in lower right corner of lightbox screen. 7. Select a printer to send print job to. Actual results: Job appears to be correctly sent to printer, but only the object title (M250 BK High Tenacity Polypropylene Knotless Netting) prints. The actual jpg element does not print, just a graphic indicating a broken link. This is true regardless of the printer chosen, even print to pdf tools. Expected results: Print output should be exactly the content of the Lightbox presentation, including the jpg image. This has been working for over a year without issue, but recent updates have broken the print ability in Firefox (currently using version 32.0.3). Issue is specific to Firefox, printing of Lightbox content still works in IE 8.
No more inbounds to bisect Last good revision: 913c11930bdb First bad revision: a200f79a7b8f Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=913c11930bdb&tochange=a200f79a7b8f
Status: UNCONFIRMED → NEW
Ever confirmed: true
So the actual page to reproduce the bug is <http://www.incord.com/netting_hardware/index.htm>, not the jpeg directly. And using the print button in the page is key. This is a regression from the first patch in bug 881996. What happens is that the actual printing is of an about:blank document. This document has a base URI that is smuggled in via the about: URI and hence via the channel (because about: knows to look for that and set the baseURI channel property). Unfortunately, we stopped calling the Reset() version that takes a channel and started calling just ResetToURI(). And we do this _after_ setting the base URI manually, so it clobbers our manual set.
Olli, any ideas how I can add an autoated test for this codepath?
Attachment #8495959 - Flags: review?(bugs)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
[Tracking Requested - why for this release]: Regression in printing about:blank documents that causes relative links to images in them to not show up.
Tracking because it is a regression but I don't think we will block the release for that.
Comment on attachment 8495959 [details] [diff] [review] Make sure to set the right base URI on the document clones we create for printing For testing... we do have some printpreview tests where document in iframe A is cloned to iframe B.
Attachment #8495959 - Flags: review?(bugs) → review+
Boris, could you land that and request the uplifts? Thanks
Comment on attachment 8495959 [details] [diff] [review] Make sure to set the right base URI on the document clones we create for printing https://hg.mozilla.org/integration/mozilla-inbound/rev/6c33145b8ebd Approval Request Comment [Feature/regressing bug #]: Bug 881996 [User impact if declined]: Printing some things doesn't work right. [Describe test coverage new/current, TBPL]: Passes existing tests, still needs a test specifically for this case. [Risks and why]: Risk is low to moderate. I'm pretty sure this is correct and safe, but this is fairly complicated code. [String/UUID change made/needed]: None.
> we do have some printpreview tests where document in iframe A is cloned Hmm. Do you know here offhand so I can crib them? ;)
Comment on attachment 8495959 [details] [diff] [review] Make sure to set the right base URI on the document clones we create for printing Low to moderate risk, it is a bit too late in the 33 cycle for this patch. However, taking it for aurora.
You need to log in before you can comment on or make changes to this bug.