WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
143952
Immediate action not functional for embedded PDFs
https://bugs.webkit.org/show_bug.cgi?id=143952
Summary
Immediate action not functional for embedded PDFs
Brent Fulgham
Reported
2015-04-20 10:18:13 PDT
There is currently no immediate action support for embedded PDFs.
Attachments
Patch
(15.83 KB, patch)
2015-04-23 15:26 PDT
,
Brent Fulgham
no flags
Details
Formatted Diff
Diff
Patch
(16.07 KB, patch)
2015-04-23 16:04 PDT
,
Brent Fulgham
no flags
Details
Formatted Diff
Diff
Patch
(19.46 KB, patch)
2015-04-23 17:26 PDT
,
Brent Fulgham
no flags
Details
Formatted Diff
Diff
Patch
(21.75 KB, patch)
2015-04-23 21:22 PDT
,
Brent Fulgham
thorton
: review+
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Brent Fulgham
Comment 1
2015-04-23 15:26:53 PDT
Created
attachment 251500
[details]
Patch
Brent Fulgham
Comment 2
2015-04-23 15:27:39 PDT
<
rdar://problem/19842365
>
WebKit Commit Bot
Comment 3
2015-04-23 15:28:52 PDT
Attachment 251500
[details]
did not pass style-queue: ERROR: Source/WebKit2/WebProcess/WebPage/mac/WebPageMac.mm:607: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 1 in 12 files If any of these errors are false positives, please file a bug against check-webkit-style.
Brent Fulgham
Comment 4
2015-04-23 15:29:22 PDT
(In reply to
comment #3
)
>
Attachment 251500
[details]
did not pass style-queue: > > > ERROR: Source/WebKit2/WebProcess/WebPage/mac/WebPageMac.mm:607: Place brace > on its own line for function definitions. [whitespace/braces] [4] > Total errors found: 1 in 12 files > > > If any of these errors are false positives, please file a bug against > check-webkit-style.
This is a Block, which is styled properly.
Tim Horton
Comment 5
2015-04-23 15:38:26 PDT
Comment on
attachment 251500
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=251500&action=review
> Source/WebKit2/WebProcess/Plugins/PluginProxy.h:127 > + WebCore::FloatRect viewRectForSelection(PDFSelection *) const override { return WebCore::FloatRect(); }
I have to say, these things are getting pretty not abstract. Maybe we should give up on the abstraction for some things and talk directly to PDFPlugin? Or make these things more generic (sufficiently generic that they could be IPCable in the case we ever want to put PDFPlugin in its own process?).
> Source/WebKit2/WebProcess/Plugins/PDF/PDFPlugin.mm:1937 > +static NSRect rectInWindowSpaceForRectInLayoutSpace(PDFLayerController* pdfLayerController, NSRect rectInLayout)
"window", really?
> Source/WebKit2/WebProcess/WebPage/mac/WebPageMac.mm:622 > + dataForSelection.contentImageScaleFactor = 1.0;
Does this work on 2x displays?
Brent Fulgham
Comment 6
2015-04-23 15:44:10 PDT
Comment on
attachment 251500
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=251500&action=review
>> Source/WebKit2/WebProcess/Plugins/PluginProxy.h:127 >> + WebCore::FloatRect viewRectForSelection(PDFSelection *) const override { return WebCore::FloatRect(); } > > I have to say, these things are getting pretty not abstract. Maybe we should give up on the abstraction for some things and talk directly to PDFPlugin? Or make these things more generic (sufficiently generic that they could be IPCable in the case we ever want to put PDFPlugin in its own process?).
I'm fine grabbing the PDFPlugin directly. Why don't I move the PDFSelection-based API out of PluginView, since other plugins are not going to deal in terms of PDFSelections. I could just pass the hit test point again, but that seems like extra work for little gain (although that is the way we would want to do this if we were IPC'ing to a separate process.
>> Source/WebKit2/WebProcess/Plugins/PDF/PDFPlugin.mm:1937 >> +static NSRect rectInWindowSpaceForRectInLayoutSpace(PDFLayerController* pdfLayerController, NSRect rectInLayout) > > "window", really?
rectInViewSpaceForRectInLayoutSpace?
>> Source/WebKit2/WebProcess/WebPage/mac/WebPageMac.mm:622 >> + dataForSelection.contentImageScaleFactor = 1.0; > > Does this work on 2x displays?
Well, images don't work at all so this is just a placeholder so it's not uninitialized. I guess I could supply 'contentScaleFactor' or something here, but since I do not supply images in general I don't know that it makes much of a difference?
Tim Horton
Comment 7
2015-04-23 16:02:19 PDT
Comment on
attachment 251500
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=251500&action=review
>>> Source/WebKit2/WebProcess/Plugins/PluginProxy.h:127 >>> + WebCore::FloatRect viewRectForSelection(PDFSelection *) const override { return WebCore::FloatRect(); } >> >> I have to say, these things are getting pretty not abstract. Maybe we should give up on the abstraction for some things and talk directly to PDFPlugin? Or make these things more generic (sufficiently generic that they could be IPCable in the case we ever want to put PDFPlugin in its own process?). > > I'm fine grabbing the PDFPlugin directly. Why don't I move the PDFSelection-based API out of PluginView, since other plugins are not going to deal in terms of PDFSelections. > > I could just pass the hit test point again, but that seems like extra work for little gain (although that is the way we would want to do this if we were IPC'ing to a separate process.
> I'm fine grabbing the PDFPlugin directly.
I ask this mostly in a bigger sense; a lot of things were added to PluginProxy/PluginView just for PDFPlugin, and in retrospect it seems silly (especially watching things with PDF in their name get added). Try talking to PDFPlugin directly and see how ugly it is. Or maybe talk to Anders.
>>> Source/WebKit2/WebProcess/Plugins/PDF/PDFPlugin.mm:1937 >>> +static NSRect rectInWindowSpaceForRectInLayoutSpace(PDFLayerController* pdfLayerController, NSRect rectInLayout) >> >> "window", really? > > rectInViewSpaceForRectInLayoutSpace?
Sure.
>>> Source/WebKit2/WebProcess/WebPage/mac/WebPageMac.mm:622 >>> + dataForSelection.contentImageScaleFactor = 1.0; >> >> Does this work on 2x displays? > > Well, images don't work at all so this is just a placeholder so it's not uninitialized. I guess I could supply 'contentScaleFactor' or something here, but since I do not supply images in general I don't know that it makes much of a difference?
Ah, I mixed this up with the TextIndicator content image scale factor.
Brent Fulgham
Comment 8
2015-04-23 16:04:38 PDT
Created
attachment 251509
[details]
Patch
WebKit Commit Bot
Comment 9
2015-04-23 16:05:55 PDT
Attachment 251509
[details]
did not pass style-queue: ERROR: Source/WebKit2/WebProcess/WebPage/mac/WebPageMac.mm:607: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 1 in 10 files If any of these errors are false positives, please file a bug against check-webkit-style.
Brent Fulgham
Comment 10
2015-04-23 17:26:39 PDT
Created
attachment 251516
[details]
Patch
WebKit Commit Bot
Comment 11
2015-04-23 17:29:39 PDT
Attachment 251516
[details]
did not pass style-queue: ERROR: Source/WebKit2/WebProcess/WebPage/mac/WebPageMac.mm:608: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 1 in 11 files If any of these errors are false positives, please file a bug against check-webkit-style.
Brent Fulgham
Comment 12
2015-04-23 21:22:03 PDT
Created
attachment 251534
[details]
Patch
WebKit Commit Bot
Comment 13
2015-04-23 21:23:07 PDT
Attachment 251534
[details]
did not pass style-queue: ERROR: Source/WebKit2/WebProcess/WebPage/mac/WebPageMac.mm:608: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 1 in 14 files If any of these errors are false positives, please file a bug against check-webkit-style.
Tim Horton
Comment 14
2015-04-24 11:26:05 PDT
Comment on
attachment 251534
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=251534&action=review
> Source/WebKit2/WebProcess/Plugins/PDF/PDFPlugin.mm:1942 > + CGFloat scaleFactor = [pdfLayerController contentScaleFactor]; > + CGPoint scrollOffset = [pdfLayerController scrollPosition];
dot notation everywhere
Brent Fulgham
Comment 15
2015-04-24 12:34:18 PDT
Committed
r183277
: <
http://trac.webkit.org/changeset/183277
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug