Quoth bug 40207 comment 7:
Open points for future improvement are:
1: tracking history (using history.pushState or hash fragment tracking).
2: mw.hook notifying about finishing the loading of the page fragment
3: using api to do all of it, instead of downloading a full page.
Version: 1.22.0
Severity: enhancement
Whiteboard: gci2013
URL: https://commons.wikimedia.org/wiki/File:MediaWikiPerformanceProfiling.pdf
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T57893 Navigating PDF/DJVU pagination could be improved | |||
| Resolved | Krinkle | T32713 Add mw.hook event for wikipage content ready | |||
| Resolved | Krinkle | T25580 Implement JavaScript mw.hooks framework | |||
| Resolved | None | T42207 Navigating PDF pagination should not require page reload |
Working on this as part of GCI. Some thoughts and a status update:
(In reply to comment #1)
- (…) having a bit of trouble with popstate event handling
(specifically, state data disappearing after the back button is clicked 2+
times?) -- will investigate further, but may come back here for guidance.
Let me just note that it will be much easier for everyone to see what's going on if they can see the code :) Submitting incomplete or work-in-progress patches to gerrit is perfectly okay, since you can always change them later.
- *Thinking* about this.
Heh, you're ambitious I see ;) I'm really itching to see what you come up with.
Change 97125 had a related patch set uploaded by Theopolisme:
Improve PDF/DJVU navigation
Made a patch anyways. The more the merrier I suppose...it's not about the specific tasks, it's about improving Wikipedia ;)
t.lam wrote:
I just started working on this and was wondering how to make my local installation of mediawiki have the multipage viewing
(In reply to comment #9)
@Thomas replied at GCI task.
Link?
Broadly, we should probably cross-reference in both directions (Bugzilla <--> GCI), if we're not already doing so.
The first two points from comment 0 are done.
The last point is not done and I'm personally not sure if it's worth doing at all (maybe if we introduce some sane client- and server-side template system into MediaWiki to avoid having two ways of rendering the same thing?), so I'll close this bug. Thanks!
Change 97363 abandoned by Brian Wolff:
Improve PDF/DJVU navigation
Reason:
Sorry, but this appears to already be done by someone else in 5e77f391a528d4bc64fc8cfe8065e254427b9ccd
The last point is actually fairly impossible without a rewrite of how the API provides media resources (since we're using (~dynamically) generated static graphics files, not the raw pdfs, etc, etc). So, yep, resolved :)
(In reply to comment #15)
The last point is actually fairly impossible without a rewrite of how the API
provides media resources (since we're using (~dynamically) generated static
graphics files, not the raw pdfs, etc, etc). So, yep, resolved :)
Actually for pdf files that's not to hard - the imageinfo module will provide urls to the thumbnail, but the general case is hard (e.g. ogg that does js stuff), and I don't think we should do it unless it would work with any potential future formats