Last modified: 2012-12-16 17:43:09 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T21536, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19536 - AJAX tabs in monobook, vector...
AJAX tabs in monobook, vector...
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: ajax
  Show dependency treegraph
Reported: 2009-07-05 18:16 UTC by Mike Połtyn
Modified: 2012-12-16 17:43 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Mike Połtyn 2009-07-05 18:16:22 UTC
Hi there!

Since MediaWiki is already exploiting AJAX in many ways, how about enabling page tabs (article, edit, talk, history, move, etc.) to be loaded at the same page without necessity of reloading the page?
Comment 1 Brion Vibber 2009-07-07 00:18:36 UTC
I'm a bit leery of this, as I'd prefer separate accessible URLs for these things. (Though to some extent one could stick things on hashes.... eh.)

Some 'quick' items loading inline might be nice, though. We can reconsider some options later once we've moved on more of the basic things and have beefed up the infrastructure more.
Comment 2 Bartosz Dziewoński 2012-11-09 12:25:49 UTC
(Reopening from RESOLVED LATER.)

There is now a way to do this with accessible URLs: the HTML5 History API, supported in all major browsers (other than IE < 10) []. In old IEs, we could resort to using hashes (as Brion suggested) or just not enable this feature.

However, to implement this, we would need a way to apply things like sortable tables or collapsible navboxes after the page load. Bug 30713 tracks this.
Comment 3 Krinkle 2012-11-09 13:26:20 UTC
The history API would allow this feature to be more transparent, but doesn't help in the implementation of it.

This bug is way too generic and not solvable in and of itself, unless it is repurposed for something like "Implement client-side html template mash-ups and convert all special pages and actions to expose their data through the API to make everything AJAX".

A "just" make tabs AJAX is not useful, nor very desirable as stuff would break all over since extensions can manipulate the page in many ways (not just the main content area, things like tabs, toolboxes, user portlet, redlink status, set cookies etc.) all kinds of things have state in the interface. For example extensions can set session, and cookies. Those can't be converted to be loaded through the API without being completely refactored or rewritten (it may be done in an automated way, but such implementation would not be acceptable or scalable by our standards).

For example, VisualEditor has an "Edit" tab that generates the surface dynamically (no reload), however this is a specific implementation for one feature in one extension.

Marking this as INVALID because it is not an implementable or thought through development issue.

Note You need to log in before you can comment on or make changes to this bug.