Closed Bug 843218 Opened 11 years ago Closed 8 years ago

pdf.js key binding for MAC

Categories

(Firefox :: PDF Viewer, defect, P3)

Product:
Firefox
Component:
PDF Viewer
Version:
19 Branch
Platform:
All
macOS
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
firefox19 --- affected
firefox20 - ---
firefox21 - ---
firefox22 - ---

People

(Reporter: alice0775, Unassigned)

References

Details

(Whiteboard: [pdfjs-c-feature]https://github.com/mozilla/pdf.js/pull/2926) 

Build Identifier:
http://hg.mozilla.org/releases/mozilla-release/rev/20238b786063
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 ID:20130215130331

pdf.js,Browser zoom level influences pdf.js contents and toolbar. 
Browser zoom level should treat like image document when viewing pdf document.(i.e.,While pdf document is opened, the browser zoom level should make 1.0.)

Steps To Reproduce:
1. Open http://www.mozilla.jp/
2. Zoom In several times (Ctrl++ Ctrl++ Ctrl++ Ctrl++ Ctrl++)
3. Open http://www.mozilla.jp/static/docs/firefox/firefox-ui-guide.pdf

Actual Results:
Browser zoom level influences pdf.js contents and toolbar.
Large toolbar size, large padding.

Expected Results:
Browser zoom level should not influence pdf.js contents and toolbar.
While pdf document is opened, the browser zoom level should make 1.0.
This isn't a critical regression, and can be fixed in a future release (although we won't track).

We'll reconsider if the volume of feedback around this issue increases.
tracking-firefox20: ? → -
tracking-firefox21: ? → -
tracking-firefox22: ? → -
Component: General → PDF Viewer
Unfortunately, the zoom level is latched for any particular document, even after restarting Firefox.  Although one can still zoom the text back to normal, one cannot view that document again with a normal toolbar.  Another problem that can happen is that the viewer can consume very large amounts of memory if the document is zoomed to a high level.  If the document is accidentally zoomed too large, it can become difficult or impossible to view.

The behavior is specific to each document.  A new document would display normally.  More details in bug 845351.  For what it's worth, zooming with the scroll wheel does not trigger this bug for me.
(In reply to VanillaMozilla from comment #3)
> Unfortunately, the zoom level is latched for any particular document, even
> after restarting Firefox.  Although one can still zoom the text back to
> normal, one cannot view that document again with a normal toolbar.  Another
> problem that can happen is that the viewer can consume very large amounts of
> memory if the document is zoomed to a high level.  If the document is
> accidentally zoomed too large, it can become difficult or impossible to view.
> 
Performance problem is another problem, please file separate bug.




> The behavior is specific to each document.  A new document would display
> normally.

Yes, it is this bug.

>More details in bug 845351. For what it's worth, zooming with
> the scroll wheel does not trigger this bug for me.

The problem seems to be another problem, please file separate bug.
s/Yes, it is this bug./Yes，if the new document is a different domain,it is this bug./
(In reply to Alice0775 White from comment #4)
> (In reply to VanillaMozilla from comment #3)
> > Unfortunately, the zoom level is latched for any particular document, even
> > after restarting Firefox.  Although one can still zoom the text back to
> > normal, one cannot view that document again with a normal toolbar.  Another
> > problem that can happen is that the viewer can consume very large amounts of
> > memory if the document is zoomed to a high level.  If the document is
> > accidentally zoomed too large, it can become difficult or impossible to view.
> > 
> Performance problem is another problem, please file separate bug.

I would say a side effect of *this* bug

> 
> 
> 
> 
> > The behavior is specific to each document.  A new document would display
> > normally.
> 
> Yes, it is this bug.
> 
> >More details in bug 845351. For what it's worth, zooming with
> > the scroll wheel does not trigger this bug for me.
> 
> The problem seems to be another problem, please file separate bug.
Sorry, I'm not trying to create bug spam.  There are probably enough comments already.

The reason I commented was to point out the interaction between two bugs and why this one is important.  The memory problem is probably bug 812777, which itself may be a duplicate, so I will not file another.
Two tests:

#1 - Use command & + on numeric keypad - NO problem

#2 - Use command & shift + on regular keyboard - Toolbar zooms with content

I tried #2 on three different PDF's and the results were the same.

Note: I saved the content-prefs.sqlite file to the desktop before doing this so I could "recover".
It's exactly the same on Windows and Linux, except that you press <Ctrl> instead of <Cmd>, as on Mac.  The bug occurs only if you press the <shift> key and the '+' on the regular keyboard.  The workaround is not to press the <shift> key.
A bit more info on MAC

Cmd + "+/=" with NO SHIFT zooms only the content in

and

Cmd + "_/-" with NO SHIFT zooms only the content out

Would seem like there is a keyboard mapping issue with pdf.js and the "normal" Firefox zoom.
This bug is not for key binding,
Please file a separate bug.
Do not hijack this bug.
Summary: pdf.js,Browser zoom level influences pdf.js contents and toolbar. (Browser zoom level should treat like image document when viewing pdf document) → pdf.js,Browser zoom level influences pdf.js contents and toolbar. (Browser zoom level should treat like mozSyntheticDocument when viewing pdf document)
(In reply to Alice0775 White from comment #11)
> This bug is not for key binding,
> Please file a separate bug.
> Do not hijack this bug.

I know what the bug is. However, the ONLY WAY I can duplicate the bug on OSX is to use the Cmd + "shift +". The bug DOES NOT occur if I use Cmd + "+" on the numeric keypad nor does it occur if I use Cmd + "+/=" with NO SHIFT.

Note that on OSX Cmd + "shift +" is used to zoom normal pages. My suggestion is that there is a conflict between pdfjs zoom and normal page zoom related to keyboard mapping; however, I haven't looked at the source code and don't have time to.

Again this is merely a suggestion based on THE ONLY WAY I CAN REPLICATE what you reported in you first post.
From mozillazine user fred6633 in Sweden on a Mac,

If I understand you right it is as following with the US keyboard when it comes to zooming in:

Cmd/Ctrl + "+" Zooms both toolbar and content.
Cmd/Ctrl + "=" Zooms only the content

With my Swedish keyboard it as following:
Cmd + "+" zooms in both content and toolbar
Cmd + "=" zooms in both content and toolbar
(In reply to Alice0775 White from comment #11)
> This bug is not for key binding,
> Please file a separate bug.

The bug is not about key binding, but key binding affects the steps to reproduce.  I don't think there's a separate bug here.


(In reply to Robertj from comment #12)
>My suggestion is that there is a conflict between pdfjs zoom and normal page
>zoom related to keyboard mapping....

That's exactly how it acts.  The explanation seems at least plausible.
I forgot to add, just so no one can miss it, on some keyboards it's necessary to (also) press the <shift> key to trigger the problem.
Keycodes might differ on different keyboard due to layout. For whom the zoom keys do not work, please go to http://www.asquare.net/javascript/tests/KeyCode.html and provide event.keyCode / onKeyDown values for the shortcuts above?
Hopefully this is what you want; all are for a PDF in the window using native pdfjs

This zooms the content AND toolbar for pdfjs on Mac

Cmd & shift & =/+

event.keyCode is '61'

This only zooms the content for pdfjs on Mac

Cmd & = [on numeric pad]

event.keyCode is '107'

This UNZOOMS the content for pdfjs on Mac

Cmd & -/_

event.keyCode is '173'

This UNZOOMS the content for pdfjs on Mac

Cmd & - [on numeric pad]

event.keyCode is '109'
I think you're looking at the wrong parameter.

event.keyCode / onKeyDown  = '61' for either <Ctl>+ or <Ctl><Shift>+ but '107' for <Ctl> <num. pad +>.

Here are the results for Linux.  The results are identical for Windows, except that the last two digits are swapped for onKeyUp.

<Ctrl> = ('+' is on same key as '=')
     	onKeyDown 	onKeyPress 	onKeyUp
event.keyCode 	'61' 	'0' 	'61''17'
event.charCode 	'0' 	'61' 	'0''0'
event.which 	'61' 	'61' 	'61''17'

<Ctrl><shift> +
 	onKeyDown 	onKeyPress 	onKeyUp
event.keyCode 	'61' 	'0' 	'61''16''17'
event.charCode 	'0' 	'43' 	'0''0''0'
event.which 	'61' 	'43' 	'61''16''17'

<Ctrl> + ('+' key on numeric keypad)
 	onKeyDown 	onKeyPress 	onKeyUp
event.keyCode 	'107' 	'0' 	'107''17'
event.charCode 	'0' 	'43' 	'0''0'
event.which 	'107' 	'43' 	'107''17'
Here, This bug is about almost key binding.
Sorry, I close this bug.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
Whiteboard: https://github.com/mozilla/pdf.js/pull/2926
I filed bug 845351, which was a duplicate. Will it be reopened now? I still want this issue resolved, and I don't want it to be closed. I'm not a computer programmer. Whether it's key binding or something else is immaterial for me. I just want a keyboard shortcut with which I can zoom in pdf documents.
(In reply to Yury Delendik (:yury) from comment #16)
> Keycodes might differ on different keyboard due to layout. For whom the zoom
> keys do not work, please go to
> http://www.asquare.net/javascript/tests/KeyCode.html and provide
> event.keyCode / onKeyDown values for the shortcuts above?

Cmd + gives this on my Swedish keyboard. 

  	onKeyDown 	onKeyPress 	onKeyUp
event.keyCode 	'171' 	'0' 	'224'
event.charCode 	'0' 	'43' 	'0'
event.which 	'171' 	'43' 	'224'

"+" is below and "?" is above on the key.

Cmd + zooms in both content and toolbar
Yury Delendik has added a <shift> key binding.  This solves it for my keyboard, but if I read correctly, the problem is not solved for order-t's Swedish keyboard.

Hoping I'm not getting in the way here, but I'm tentatively reopening it, as it is not marked as FIXED, and it isn't INCOMPLETE.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Priority: -- → P3
Whiteboard: https://github.com/mozilla/pdf.js/pull/2926 → [pdfjs-c-feature]https://github.com/mozilla/pdf.js/pull/2926
I close this, because this bug was hijacked by MAC user.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → INCOMPLETE
Alice, if you want this fixed, you need to stop closing it.  This bug is where all the information is, and where the work is taking place.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
mozSyntheticDocument just forces to use full zoom feature (vs text-only zoom) -- it will not help to solve the original issue since pdf.js toolbar will still be zoomable. Changing title to remove poor solution/analogy.
Summary: pdf.js,Browser zoom level influences pdf.js contents and toolbar. (Browser zoom level should treat like mozSyntheticDocument when viewing pdf document) → Browser zoom level influences pdf.js contents and toolbar
No,

See, http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-fullZoom.js#258
If pdf.js is treated like mozSyntheticDocument, zoom level is always set to 1.
Then the problem(comment #0) is gone.
I see, so the problem is only to fix the initial zoom, but it will not be a problem if user will change it via menu or while the document out of focus (e.g. bug 786674). Is it the correct assumption?
(In reply to Yury Delendik (:yury) from comment #28)
> I see, so the problem is only to fix the initial zoom, but it will not be a
> problem if user will change it via menu or while the document out of focus
> (e.g. bug 786674). Is it the correct assumption?

Yes, bug 786674 is a different bug.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 8 years ago
OS: All → Mac OS X
Resolution: --- → INCOMPLETE
Summary: Browser zoom level influences pdf.js contents and toolbar → pdf.js key binding for MAC
You need to log in before you can comment on or make changes to this bug.