Created attachment 115952 [details] Screen shot of URL The process of printing a label on usps.com results in a label being downloaded in Safari 5.1. Does not currently work in Webkit. This process used to result in a print dialogue, however that doesn't happen anymore in either Safari or Webkit. https://sss-web.usps.com/cns/printPreparation.do
<rdar://problem/10463059>
Went through the entire label creation & printing process, address book bug 73657/73183 has been fixed. Still unable to get the label to print. Anything I can do to assist or provide more information? Version 5.1.2 (7534.52.7, r101927) https://sss-web.usps.com/cns/printPreparation.do
Thank you. This cause of this problem is well understood, and its importance is also well understood.
Created attachment 120760 [details] Make BuiltInPDFView execute JavaScript in PDF documents with a Doc object capable of printing the frame Together with fixing bug 75232, this patch resolves the issue.
Created attachment 120761 [details] Make BuiltInPDFView execute JavaScript in PDF documents with a Doc object capable of printing the frame
Comment on attachment 120761 [details] Make BuiltInPDFView execute JavaScript in PDF documents with a Doc object capable of printing the frame View in context: https://bugs.webkit.org/attachment.cgi?id=120761&action=review Looks great. Does this depend on bug 75232? > Source/WebKit2/WebProcess/Plugins/PDF/BuiltInPDFView.cpp:838 > + WebPage* page = frame->page(); > + if (!page) We have a check for pageless frame here, but not in BuiltInPDFView::initialize() or BuiltInPDFView::isActive(). Can page actually be null? > Source/WebKit2/WebProcess/Plugins/PDF/BuiltInPDFView.cpp:841 > + page->sendSync(Messages::WebPageProxy::PrintFrame(frame->frameID()), Messages::WebPageProxy::PrintFrame::Reply()); I'd have routed this through WebCore, for instance to make use of PageGroupLoadDeferrer once Chrome::print starts using it. > Source/WebKit2/WebProcess/Plugins/PDF/BuiltInPDFView.h:35 > +typedef const struct OpaqueJSContext* JSContextRef; > +typedef struct OpaqueJSValue* JSObjectRef; > +typedef const struct OpaqueJSValue* JSValueRef; :( > Source/WebKit2/WebProcess/Plugins/PDF/BuiltInPDFView.h:139 > - virtual void disconnectFromPage() { m_page = 0; } > + virtual void disconnectFromPage() { m_frame = 0; } This is now a little bit surprising.
> Does this depend on bug 75232? I now see the answer above.
Comment on attachment 120761 [details] Make BuiltInPDFView execute JavaScript in PDF documents with a Doc object capable of printing the frame View in context: https://bugs.webkit.org/attachment.cgi?id=120761&action=review >> Source/WebKit2/WebProcess/Plugins/PDF/BuiltInPDFView.cpp:838 >> + if (!page) > > We have a check for pageless frame here, but not in BuiltInPDFView::initialize() or BuiltInPDFView::isActive(). Can page actually be null? I’m quite certain it *cannot* be null in initialize(). I’m going to be paranoid and add a null check in isActive() rather than try to reason about lots of code outside this class. In this function, in particular, I don’t want to make any assumptions, in case Doc is ever extended to have something like setTimeout. >> Source/WebKit2/WebProcess/Plugins/PDF/BuiltInPDFView.cpp:841 >> + page->sendSync(Messages::WebPageProxy::PrintFrame(frame->frameID()), Messages::WebPageProxy::PrintFrame::Reply()); > > I'd have routed this through WebCore, for instance to make use of PageGroupLoadDeferrer once Chrome::print starts using it. Good idea. I’ll do that. >> Source/WebKit2/WebProcess/Plugins/PDF/BuiltInPDFView.h:35 >> +typedef const struct OpaqueJSValue* JSValueRef; > > :( You’ll thank me when JavaScriptCore public headers change and you don’t have to recompile all files that include this header!
Created attachment 120831 [details] Make BuiltInPDFView execute JavaScript in PDF documents with a Doc object capable of printing the frame
Fixed in <http://trac.webkit.org/r103860>.