Last modified: 2011-03-13 18:04:49 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 T28175, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26175 - Revert JS-based content loader from diff page
Revert JS-based content loader from diff page
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
FlaggedRevs (Other open bugs)
unspecified
All All
: Lowest major with 1 vote (vote)
: ---
Assigned To: Rob Lanphier
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-30 19:15 UTC by Bergi
Modified: 2011-03-13 18:04 UTC (History)
11 users (show)

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


Attachments

Description Bergi 2010-11-30 19:15:07 UTC
Since there Bug 25289 went live there are several problems. Some are reported in onw Bugs, e.g Bug 26163 (others are Bug 26128 - not specifc but based on that - and Bug 26129 - minor).
The bigger problem is the use of ajax technologies. At first, it isnt faster at all pages as mostly the content is loaded one after the other and instead of together. Then, this technology messes up with users who dont use javascript, they have to follow a link to see the page content. It hurts usability and the eqality point in good web design.
At last, the content is loaded after all the scripts are run. Every Gadget which should act to the page doesnt work at diffs, mostly critisized the section-edit-movement. You can find a lot af examples there:
http://de.wikipedia.org/wiki/Wikipedia_Diskussion:Projektneuheiten
http://de.wikipedia.org/wiki/Wikipedia:FzW#Kategorien_im_Difflink_nicht_sichtbar_-_ein_Bug.3F

So we need to put a onContentLoad-function-Hook to work, which runs when new content is loaded, before enabling such ajax things. Until a solution I propos to undo the implemented revisions.
Comment 1 Aaron Schulz 2010-11-30 20:12:48 UTC
(In reply to comment #0)
> Since there Bug 25289 went live there are several problems. Some are reported
> in onw Bugs, e.g Bug 26163 (others are Bug 26128 - not specifc but based on
> that - and Bug 26129 - minor).
> The bigger problem is the use of ajax technologies. At first, it isnt faster at
> all pages as mostly the content is loaded one after the other and instead of
> together. Then, this technology messes up with users who dont use javascript,
> they have to follow a link to see the page content. It hurts usability and the
> eqality point in good web design.
> At last, the content is loaded after all the scripts are run. Every Gadget
> which should act to the page doesnt work at diffs, mostly critisized the
> section-edit-movement. You can find a lot af examples there:
> http://de.wikipedia.org/wiki/Wikipedia_Diskussion:Projektneuheiten
> http://de.wikipedia.org/wiki/Wikipedia:FzW#Kategorien_im_Difflink_nicht_sichtbar_-_ein_Bug.3F
> 
> So we need to put a onContentLoad-function-Hook to work, which runs when new
> content is loaded, before enabling such ajax things. Until a solution I propos
> to undo the implemented revisions.

Gadgets that alter or scrap HTML will break from time to time when the UI changes, there isn't always a way around that. The UI cannot stagnate.

Also, the content needs to load the preview *after* the rest of the page. The whole point of using AJAX is to let the user see the diff without having to wait on the preview (which can take forever).

That said, I'd agree that the category/IW link and the breakage of local site CSS customizations is particularly annoying. The committer has made a priority of these items I believe.
Comment 2 Peter Spieß 2010-12-01 12:38:24 UTC
Please undo this function until it works orderly. It's very annoying that this buggy feature hinders me to work properly.
Since I'm an active Wikipedian (this is since 2005) it always used to be that new software features only go live when they work fine. Why is this dealt differently this time?
Comment 3 Umherirrender 2010-12-01 14:32:42 UTC
It is possible to have a hook for this? bug 23580 has done that for the LivePreview Feature of core. Maybe adapt from there.

Thanks.
Comment 4 Bergi 2010-12-01 16:37:38 UTC
Hm, how about a more general event for ajax subjects? I thought about passing the new elements as a parameter to bound functions. Just like

$j( mw ).trigger( "AjaxLoadDone", {
   ajaxtype: "LivePreview",
   elements: copyElements,
   region: "content"
} );

respectively here

$j( mw ).trigger( "AjaxLoadDone", {
   ajaxtype: "DiffContentloader",
   elements: "#mw-fr-revisioncontents",
   region: "content"
} );

For "region" I propose values as sidebar, content, interwiki, categories... (stipulated)
So then every function just has to check "region" and potentially "elements", instead of binding its handlers to every single (unknown?) load-event.
Comment 5 Rob Lanphier 2010-12-13 22:07:22 UTC
I'm marking this one as "wontfix" (and clarifying the title).  There are a couple of fixes that we're planning to roll out next week that will make address some of the shortcomings addressed here.  Additionally, I've filed bug 26328 to discuss the possibility of a callback for gadget writers. 

We would consider making this a user-configurable option (please file a separate bug for that if you're interested), but this will be a pretty valuable improvement once we get the kinks worked out of it.
Comment 6 Krinkle 2011-02-24 15:35:12 UTC
Aside from gadgets, core functionality (as of 1.17) such as TOC-toggle, collapsible elements, mw.util.$content etc. are also messed up (potentially $.fn.placeholder and $.fn.checkboxShiftClick as well)

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


Navigation
Links