New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add scrolling options to PDFJS context menus. #2417
Add scrolling options to PDFJS context menus. #2417
Conversation
b55bd47
to
1ff6586
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is specific to PDF.js, it should probably not touch PDFPlugin code
It looks like to get outside of PDFPlugin we will want to register some event handler outside of it. WebCore::callDefaultEventHandlersInBubblingOrder eventually calls HTMLPluginElement::defaultEventHandler(). Maybe this could be done inside WebCore::PDFDocument or is there perhaps a better area? |
Actually I don't think PDFDocument is the right place to do this. I'll need to look around a bit |
1ff6586
to
c72b4aa
Compare
c72b4aa
to
d670863
Compare
d670863
to
c005256
Compare
This PR title seems overly generic. It should probably say something about PDFjs or PDF. |
c005256
to
5b20186
Compare
Updated! |
5b20186
to
dc8d657
Compare
appendItem(StopItem, m_contextMenu.get()); | ||
else | ||
appendItem(ReloadItem, m_contextMenu.get()); | ||
if (frame->isMainFrame() || (frame->page() && !frame->ownerElement()->document().isPDFDocument())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to null check frame->ownerElement() instead of frame->page()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the null pointer check here. Also removed the frame->page() check since the more specific if branches are checking for them along with other checks below.
#endif | ||
} | ||
|
||
if (frame->page() && !frame->isMainFrame()) | ||
if (frame->page() && !frame->isMainFrame() && !frame->ownerElement()->document().isPDFDocument()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What guarantees that frame->ownerElement() is non null?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I had some misunderstandings between frames and pages. I will definitely need to add a null check for that. If we got rid of the frame->page() check here would that be ok? Since a frame could get detached from a page (although I don't entirely know what that scenario would be), would we want to check that or do you not think it would matter in this case? Also, it looks like I might want to add a null check for the document as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might want to add a null check for the document as well?
No, document() is a reference, not a pointer so it cannot be null.
But when you dereference this pointer (frame->ownerElement()) without a null check, this looks dangerous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the frame->ownerElement null pointer check here
dc8d657
to
f86f94d
Compare
Can you guard the new code behind |
f86f94d
to
3e8dad2
Compare
2732914
to
3deaa11
Compare
6adc716
to
704f9bd
Compare
case ContextMenuAction::ContextMenuItemPDFSinglePageContinuous: | ||
case ContextMenuAction::ContextMenuItemPDFTwoPages: | ||
case ContextMenuAction::ContextMenuItemPDFTwoPagesContinuous: | ||
return true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sgill26 It would be good to move these up and share the return true;
with the other cases in a follow-up patch (maybe the patch where you hook up the context menu items into PDF.js).
Commit message contains (OOPS!), blocking PR #2417 |
Commit message contains (OOPS!) and no reviewer found, blocking PR #2417 |
941bdbd
to
a9d682f
Compare
ContextMenuItem SinglePageItem(ActionType, ContextMenuItemPDFSinglePage, contextMenuItemPDFSinglePage()); | ||
ContextMenuItem SinglePageContinuousItem(ActionType, ContextMenuItemPDFSinglePageContinuous, contextMenuItemPDFSinglePageContinuous()); | ||
ContextMenuItem TwoPagesItem(ActionType, ContextMenuItemPDFTwoPages, contextMenuItemPDFTwoPages()); | ||
ContextMenuItem TwoPagesContinuousItem(ActionType, ContextMenuItemPDFTwoPagesContinuous, contextMenuItemPDFTwoPagesContinuous()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Indentation.
a9d682f
to
13e2ff7
Compare
https://bugs.webkit.org/show_bug.cgi?id=237059 rdar://89315125 Reviewed by Aditya Keerthi. This patch adds scrolling options to the context menu when right clicking on a PDF that is being rendered in PDFJS. It is important to note that this patch only adds the options to the context menu in appearance only. Linking the options to the actual implementation in PDFJS will be done in another patch. By taking advantage of the current context menu code, such as in ContextMenuController, we can try to keep the PDF code as close to the rest of the context menu code. For example, we would have have to go through WebPageProxy::showPDFContextMenu inside WebPageProxyMac, which the current PDFPlugin code does. The only special consideration that needs to be made is within ContextMenuController::populate. We need to be able to determine that the PDF context menu items must be added to the context menu. We can do this by determining that the current frame is an iframe (!frame->isMainFrame) and that the owning document is a PDFDocument (frame->ownerElement()->document().isPDFDocument()). Similarly, in already existing cases where the code checks for frame->page(), we must add an extra condition that the owning document is NOT a PDFDocument so that we do not add any extra context menu items to PDF context menus and remain consistent with the current PDF context menu. * Source/WebCore/en.lproj/Localizable.strings: * Source/WebCore/page/ContextMenuController.cpp: (WebCore::ContextMenuController::checkOrEnableIfNeeded const): (WebCore::ContextMenuController::populate): Goes through and determines where to add the PDF context menu items. We need to make sure that the normal context menu remain the same (when not viewing a PDF) and also to make sure that the PDF context menu remains consistent with the current implementation. * Source/WebCore/platform/ContextMenuItem.cpp: (WebCore::isValidContextMenuAction): * Source/WebCore/platform/ContextMenuItem.h: Adds the new context menu scrolling items to the ContextMenuAction enum. * Source/WebCore/platform/LocalizedStrings.cpp: (WebCore::contextMenuItemPDFSinglePage): (WebCore::contextMenuItemPDFSinglePageContinuous): (WebCore::contextMenuItemPDFTwoPages): (WebCore::contextMenuItemPDFTwoPagesContinuous): * Source/WebCore/platform/LocalizedStrings.h: * Source/WebKitLegacy/mac/WebView/WebHTMLView.mm: (toAction): (toTag): Canonical link: https://commits.webkit.org/253130@main
13e2ff7
to
d50f30c
Compare
Committed 253130@main (d50f30c): https://commits.webkit.org/253130@main Reviewed commits have been landed. Closing PR #2417 and removing active labels. |
d50f30c