Ensure that the 'pagechanging' event is triggered on load, to avoid incorrect initial button state (PR 7289 followup)

[Snuffleupagus]

With the changes in PR #7289, we no longer dispatch a 'pagechanging' event on load. Since most PDF documents open on the first page, this means that the previous and firstPage buttons are not correctly disabled.

A picture is worth a thousand words:

/cc @yurydelendik

[Snuffleupagus]

/botio-linux preview

[pdfjsbot]

From: Bot.io (Linux)

---

Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://107.21.233.14:8877/dbbc44bf362a39f/output.txt

[pdfjsbot]

From: Bot.io (Linux)

---

Success

Full output at http://107.21.233.14:8877/dbbc44bf362a39f/output.txt

Total script time: 1.03 mins

Published

• Viewer: http://107.21.233.14:8877/dbbc44bf362a39f/web/viewer.html
• B2G Viewer: http://107.21.233.14:8877/dbbc44bf362a39f/extensions/b2g/content/web/viewer.html
• Extension: http://107.21.233.14:8877/dbbc44bf362a39f/extensions/firefox/pdf.js.xpi

[yurydelendik]

Looks like it's a little bit confusing. Can we try to move https://github.com/mozilla/pdf.js/blob/master/web/app.js#L1956-L1962 somewhere e.g. in updateUIToolbar() function on call it, first, on viewer initialization, and then on pagechanging. (We can move more stuff there e.g. scale change or file opened)

[Snuffleupagus]

@yurydelendik Does this look like what you had in mind master...Snuffleupagus:updateUIToolbar?

[yurydelendik]

@Snuffleupagus yes, but I'm not sure we need to provide any args to the function (can it pull all needed info from the object states)

[yurydelendik]

Approach in #7405 (comment) looks good. We can re-iterate with further optimizations once it's landed to fix the regression.

[Snuffleupagus]

but I'm not sure we need to provide any args to the function (can it pull all needed info from the object states)

Sorry, I'm not sure that I understand where you're suggesting that we should get the values from if we're not passing them into the method!?
I figured I should ask, since if it's easy to address this comment, I might as well try and fix it before submitting the PR (less code churn that way).

[yurydelendik]

Ideally, we shall have a function that if we call it, the toolbar state will be updated to the state of the model the viewer in (without knowing who calls it, but atm resetNumPages or scaleValue provide this information). I anticipate that this function will be call at any event, e.g. initializing/zooming/scrolling/document change/etc. or combination of several. It not a problem, but it will be good to move/split this method into several (for each toolbar, context menu) and call them from the viewer's.

[Snuffleupagus]

Approach in #7405 (comment) looks good. We can re-iterate with further optimizations once it's landed to fix the regression.

OK, I'm just going to submit a PR with what I've got for now, and we can improve on this later on.
Closing as superseded by PR #7458.