Skip to content
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

When using the hand tool, sometimes the secondary tool bar will go behind the document #5452

Closed
ghost opened this issue Oct 28, 2014 · 5 comments · Fixed by #16896
Closed

Comments

@ghost
Copy link

ghost commented Oct 28, 2014

Win7 64b ( tried using pdfjs 1.0.473 and 1.0.712 )

To reproduce I simply use the hand tool and scroll pages with it for a bit, and then click on the button to open the secondary menu. Sometimes when I do this it gets stuck behind the document. When this happens a page refresh is required to fix it. This doesn't happen every time so reproducing it is somewhat awkward. IE11 reproduces with a higher frequency, although I was also able to reproduce in FF32 as well:

handtoolissue

@timvandermeij
Copy link
Contributor

I have personally never seen that happen before. Could this be a z-index thing?

@Rob--W
Copy link
Member

Rob--W commented Oct 29, 2014

The effect can be reproduced in Chromium 38.0.2125.106 as follows (though I'm not certain whether the cause is the same):

  1. Open a PDF in the PDF.js viewer.
  2. Enable the hand tool.
  3. Click on the menu to open it.
  4. Drag the document up/down.

Observe that at step 4, the menu goes behind the canvas. And after a while, the menu simply disappears.

In Firefox, the menu always stays open.

@ghost
Copy link
Author

ghost commented Oct 29, 2014

I should also have noted I'm in Win7 64b using pdfjs 1.0.473 ( and recently tried 1.0.712 as well ). This happened most often in IE11, but also was able to make it happen in FF33.

I've noticed now that if I follow the steps above, and drag the document ( with hand tool enabled BUT scrolling with the scrollbar instead of the hand ) this reproduces it every time in IE11. In FF33 this makes it go behind temporarily but it comes back to the front as soon as I stop scrolling.

@Snuffleupagus
Copy link
Collaborator

Is this still an issue?

@Rob--W
Copy link
Member

Rob--W commented Mar 10, 2020

I can still reproduce using the STR from #5452 (comment) in Chromium 80.0.3987.132. The menu goes behind the canvas, but doesn't completely disappear though.

Abishek-Jayan added a commit to Abishek-Jayan/pdf.js that referenced this issue Aug 29, 2023
…sToolbar to resolve toolbars going behind canvas issue (bug 5452). While my fix was targeted toward the secondaryToolbar, I noticed that the issue regarding the toolbars going behind the canvas on using the hand tool persisted for the findToolbar as well. So to fix I just updated their common z-index value to be just higher than the screen grabbing div's z-index. Issue seems to be resolved in both Chrome,Brave and Firefox. This is a fix for mozilla#5452
Abishek-Jayan added a commit to Abishek-Jayan/pdf.js that referenced this issue Aug 29, 2023
…sToolbar to resolve toolbars going behind canvas issue (bug 5452). While my fix was targeted toward the secondaryToolbar, I noticed that the issue regarding the toolbars going behind the canvas on using the hand tool persisted for the findToolbar as well. So to fix I just reduced the z-index of the .grab-to-pan-grabbing class to 29000 and updated its comment accordingly. I tested the fix extensively in Chrome, Firefox and Brave and it seems to be fixed. This is a fix for mozilla#5452
Abishek-Jayan added a commit to Abishek-Jayan/pdf.js that referenced this issue Aug 29, 2023
… going behind canvas issue (bug 5452). While my fix was targeted toward the secondaryToolbar, I noticed that the issue regarding the toolbars going behind the canvas on using the hand tool persisted for the findToolbar as well. So to fix I just reduced the z-index of the .grab-to-pan-grabbing class to 29000 and updated its comment accordingly. I tested the fix extensively in Chrome, Firefox and Brave and it seems to be fixed. This is a fix for mozilla#5452
@Snuffleupagus Snuffleupagus linked a pull request Sep 4, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants