Deleting current page after mouse selection operation that results in nothing being selected

[Jensen Head]

Steps

1. Select a page in the Thumbnails panel.
2. Switch to Edit Objects mode.
3. Drag the selection frame so that it does not capture any objects.
4. Press Delete.

Actual behavior

The current page is deleted.

Expected behavior

Nothing happens.

PDF-XChange Editor 10.5.2, build 395 (Enhanced OCR)
Microsoft Windows 10.0.19045.5854

[Daniel - PDF-XChange]

Hello, Jensen Head

This is intended, Deletion is context sensitive, to ensure we do not mistakenly delete items which are not in active use/focus.

Step 3 in your process changes your focus away from the thumbnails pane and over to the main document area. This prevents the "delete page" action which the thumbnails pane would initiate from happening, because the delete command is sent to the page area instead. In practice, you have told the editor "delete the selected page content or comment items", immediately after ensuring you do not have anything selected.

Apologies, I both misread the original post, and was mistaken on the focus based handling, please see Rakunavi's message below, and my second post in this topic. The Dev team will be reviewing this situation in the future.

Kind regards,

[rakunavi]

Hello Daniel,

It seems that you might not fully grasp Jensen Head's argument. He is not saying that pages are not deleted, but rather that they are unintentionally deleted. The current behavior could lead to the danger of unintended data loss.

He has written a procedure that is limited to the Thumbnails pane and Edit Objects mode, but in fact it applies not only to the Thumbnails pane, but also to the Bookmarks pane, the Named destinations pane, and so on (*). It also applies to the Select Comments tool as well as the Edit Objects mode.
(*) The others are the Layers pane, the Attachments pane and the Tags pane.

For example, here is the verification procedure. As usual, I start the verification with the default settings.

1. Open the Thumbnails pane, the Bookmarks pane, and the Search pane.
2. Select page 8 in the Thumbnails pane.
3. Select page 8 in the Bookmarks pane.
4. Enter the keyword "text" in the Search pane to search. Select page 8 of the search results.
5. Select the red rectangles on page 8 with the Select Comment Tool and delete them with the Delete key.
6. Press the Delete key again, and a confirmation dialog box for deleting page 8 of the Thumbnails pane will appear.
7. If "Yes" is selected in the dialog box, page 8 is deleted.
8. Close the Thumbnails pane. Page 8 (originally page 9) is displayed on the screen.
9. Select the red rectangles on page 8 (originally page 9) with the Select Comment Tool and delete them with the Delete key.
10. Press the Delete key again, and a confirmation dialog box for deleting the item for page 8 (already deleted) of the Bookmarks pane will appear.
11. If "Yes" is selected in the dialog box, the bookmark for page 8 (already deleted) is deleted.

• Animation1.gif

• sample.pdf

Notice that just before pressing the Delete key again in Step 6 or Step 10, the Page View, which you call the main document area, is still active, and the Thumbnail and Bookmarks panes are never active. The biggest issue is that the Delete key is having an effect on those inactive panes. Incidentally, the search in the Search pane in Step 4 is unrelated to the problem itself, but is added as a step to create a situation where the Thumbnails pane or Bookmarks pane is not the most recently used pane, let alone inactive.

Most users probably set the confirmation dialog box for deletion not to be displayed, in which case pages and bookmarks are deleted without the user's intention. It is common practice for anyone to select a thumbnail or bookmark, navigate to the desired page, and then perform editing operations in Page View. Most users would not expect that pressing the Delete key more than necessary in Page View would delete the thumbnail or bookmark they accessed at the beginning of their work. Although they are indeed selected items in their respective panes, it is natural to assume that the Delete key has no effect as long as the pane is inactive.

Of course, the page or bookmark will not be deleted unless the Delete key is pressed one extra time in Page View in Step 6 or Step 10. However, it is quite common to press the Delete key a little extra time while doing any editing work in Page View. In such cases, it is normal to sound an error and do nothing, as was the case until build 336, and it is clearly excessive to delete one item after another that has the focus in an open pane, even though the pane is inactive.

Incidentally, Acrobat (version 10.1.16) and Foxit PDF Editor (version 13.1.2.22442) do not delete pages or bookmarks in such cases. For reference, a verification video in Acrobat is shown below.

• Animation2.gif

I checked older builds of PDF-XChange Editor and found that the current behavior has been occurring since build 337 released on Apr 13th, 2020. Until build 336, even PDF-XChange Editor did not unintentionally delete as well as other applications.

• Animation3.gif

This is intended, Deletion is context sensitive, to ensure we do not mistakenly delete items which are not in active use/focus.

I totally agree with you about the importance of not mistakenly deleting items which are not in active use/focus, but based on that concept, I would think that the behavior I indicated above would rather lead to the decision that it is unintentional, i.e., a problem. I am surprised that your assessment is completely opposite to mine. From my perspective, this issue requires urgent improvement due to the risk of unintended data loss, as I mentioned at the beginning of this post. I wonder if there is some misunderstanding.

Thank you for taking the time to read this message.

Best regards,
rakunavi

- PDF-XChange Editor PRO Version: 10.6.0 build 396
- OS Version: Windows 11 Pro / Home 24H2 Build 26100.4061
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL

[Daniel - PDF-XChange]

Hello, rakunavi

You are correct that this was a misreading on my part, I saw the "Expected" and "Actual" statement in reverse... My Apologies Jensen, and Thank you Rakunavi for catching this.

Surely enough in testing, this does happen. It is worth noting that you do in all cases, see a dialogue prompt asking to confirm you wish to perform the specified action, so there could be an argument made that this inherently removes the "accidental" aspect of the worries. Following that, it seems my understanding of the focused context was incorrect... Taking into consideration the checks that do occur, I am unsure if this is strictly something that could be classified as a "bug", but this is at least different enough from all of our expectations that I will pass it along to the Dev team for review.

There is a chance changes will be rejected here because of the clear safeties in place, but I will let you know when I hear back in either case. As you said, it is possible for users to have hidden these items, and if the pane in question is not visible, than no such action will occur.

[Edit] The Dev team has agreed to look into it further, at the very least!
RT#7496: Bug? Delete key affects unfocused panes

Kind regards,

[rakunavi]

Hello Daniel, thank you for creating the ticket.

It seems to me that the following users (probably the majority of users) may have unknowingly erased some of the pages and bookmarks of documents they have worked with in PDF-XChange Editor in the past five years.

• Users who leave the confirmation dialog box set to disabled, assuming that build 337 and later builds will work the same as build 336 and earlier (including PDF-XChange Viewer).
• Users who have disabled the confirmation dialog box based on the mistaken expectation that it will behave like other applications.
• Users who have disabled the display of dialog boxes without much thought.
• Users who are in the habit of operating applications with the Bookmarks pane, Thumbnails pane, etc. open.

Since data is lost without the user's notice, some users may not be able to link this to the cause and may be using the application with doubts about the reliability of its operation. In addition, the measure of enabling the confirmation dialog box significantly worsens the daily usability in the Thumbnails and Bookmarks panes.

There seems to be no benefit at all commensurate with such dangerous behavior, and I hope that the developers understand the dangers and improve the situation as soon as possible. If there is some benefit to this behavior, I would love to hear about it. I comment for your information because there seems to be a divergence in the assessment of risk between users and PDF-XChange.

Please give my best regards to developers.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you for the examples, I will be sure to add note of those possible cases to the ticket.

I should also mention that my assessments are disconnected from those of the company. I merely express my personal thoughts on each matter, because I prefer to be honest with my expectations.

Perhaps I am just too stubborn to always use a mechanical "Thank you for XYZ, it will be done" response, but I prefer to add a more human touch where possible. Making mistakes or misjudgments (and typos, lots of typos!) is sometimes a part of that, but that presentation does not affect the actions I take "behind the screen".

Regardless of my own assessment, I do always pass these on to the Dev team for their own independent review. In many cases, they come to the same conclusion I did, and a request may see the approval or rejection I predicted.
In others like we see here, the Dev team did have a different interpretation of the situation from my own, and decided it requires additional investigation on their end. Such cases usually translate to some changes being made, though not always the changes we expected. For that we will have to wait and see.

Kind regards,

[rakunavi]

Hello Daniel, thank your for your reply. I have been well aware of your assessment attitude and appreciate it.

At this message, I would like to address a problem that seems to share the same root cause as the one described above. That is, the problem reported below works differently in builds up to build 336 and in later builds.

If you create a guide immediately after clicking on a page in the Thumbnails pane and then delete the guide using the context menu or the Delete key, the page is deleted instead of the guide. Also, if you click on a page in the Thumbnails pane while a guide has already been created, and then delete the guide using the context menu or the Delete key, the page will be deleted instead of the guide as well.

In the following verification video, a new document with a total of 10 pages is created, and the guides are deleted in different ways in the first and second halves of the video.

• Case 1 : Create a guide after clicking on a page in the Thumbnails pane, followed by deleting that guide.
• Case 2 : Creating a guide on a page in advance, followed by clicking on the page in the Thumbnails pane, then selecting and deleting the guide.

In each case, the guide is deleted in one of the following two ways.

• Select Delete command from the context menu.
• Delete by using the shortcut key Delete.

In the entire video, there are a total of four ways to delete guides: in build 336, the pages are not deleted and remain at a total of 10 pages; in build 396, the Delete Page dialog is displayed in all four patterns. In other words, if you have disabled the display of the confirmation dialog, four pages may be deleted unintentionally.

• Animation1.gif
  
  
  Animation2.gif

Please be sure to use a multi-page document when verifying the above behavior with the latest build. This is because if the total number of pages is one, the Delete command is grayed out in the context menu and cannot be executed, and the Delete key does not respond, due to the fact that the Thumbnails pane does not accept page deletions. Selecting a guide and pressing the right-click button brings up a context menu, but it is very unintuitive that some of the commands in it, including Delete, work for the Thumbnails pane. This seems to me to be unintended behavior by the developers, along with the problem I originally reported.

• figure.png

RT#7496: Bug? Delete key affects unfocused panes

In the previous post, I reported this problem as occurring only for the Delete key, but as I have shown, Ctrl+X, Ctrl+C, Ctrl+V, etc. also work for the Thumbnails pane. Therefore, it may be more accurate to not limit the title of the ticket to the Delete key.

Thank you for taking the time to read this message.

Best regards,
rakunavi

- PDF-XChange Editor PRO Version: 10.6.0 build 396
- OS Version: Windows 11 Pro / Home 24H2 Build 26100.4061
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you for the added detail and the information about the additional commands still working. The ticket number remains the same, but I have updated the details of it to reflect this information.

Kind regards,