Last modified: 2014-11-17 10:35:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8679 - Consider blacklisting CSS attributes "z-index" and "position" in wiki text
Consider blacklisting CSS attributes "z-index" and "position" in wiki text
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Low enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 7303 14346 15066 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2007-01-17 20:05 UTC by Invalid Account
Modified: 2014-11-17 10:35 UTC (History)
5 users (show)

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


Description Invalid Account 2007-01-17 20:05:31 UTC
I made a sample here

It's some crap Encyclopedia Dramatica is spamming on lots of wikis. I replaced the foul language in it 
with things like "buggycode" and I'd rather not link to their website. Try viewing the sample I gave in 
different web browsers as it gets worse depending on which used.

It would be good to fix page rendering so this code doesn't work.
Comment 1 Invalid Account 2007-01-17 20:06:09 UTC
This should be all on one line:

Comment 2 Rob Church 2007-01-17 20:07:59 UTC
This is quite a common form of vandalism, and I suppose we could block it with
$wgSpamRegex on Wikimedia sites, though it would just encourage further variants.

Two solutions here; either continue to revert it, or we could consider
blacklisting further CSS attributes, such as z-index etc.
Comment 3 Antoine "hashar" Musso (WMF) 2007-01-17 20:08:59 UTC
Should we disable the value 'position:fixed' in the sanitizer ?
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-26 00:04:43 UTC
There's not really any reason to allow position: fixed in article content, probably, but this could 
easily be just as disruptive with position: absolute or relative or whatever.  Any of those could 
overwrite stuff outside the article box.  But absolute and relative positioning are standard, useful 
CSS properties.  Silly vandalism like this can be dealt with easily enough.  I suggest WONTFIX.
Comment 5 Invalid Account 2007-02-01 02:01:16 UTC
People seem to use this or some other funky HMTL code to give themselves messed up user and talk 
pages with buttons and links outside the normal text window.
Comment 6 Titoxd 2007-04-22 08:04:27 UTC
Well, this would break [[Template:Featured article]],
[[Template:Pp-semi-protected]], [[Template:Spoken]], and others, to name a few.
Comment 7 Mark Ryan 2007-04-22 14:45:14 UTC
... So build-in functionality to make those sorts of icons in the top right of 
articles. This functionality needs to be removed. The potential for abuse is 
too great; I'm surprised it hasn't been used maliciously yet.

See, for example,

The form at the destination there just leads right back to Wikipedia, but it 
could just as easily be used to silently capture usernames and passwords for 
unspecified future abuse.
Comment 8 Gregory Maxwell 2007-04-22 17:13:02 UTC
Come now, separation of code and presentation would be good.  At a minimum we
could allow the introduction of fancy positioning stuff via items in MediaWiki
namespace... this would preserve the operation of sane site wide things, and
prevent the introduction of ugly one-offs that tend to have poor usability or
violate the principle of least surprise.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-22 20:17:35 UTC
Take a look at, for instance, the link created by ImageMap to the source image's
page.  That uses absolute positioning.  Yes, separating content and markup is
good, but it's not really practical at present while permitting reasonably
flexible formatting, since it's so much slower to have to get sysops involved. 
Banning these properties entirely is overkill.  What should be prevented is
overlaying anything on top of interface elements; that's bug 9526, and should be
possible to accomplish without resorting to this.
Comment 10 Mark Ryan 2007-04-23 02:08:16 UTC
Would there be any way of preventing such absolute positioning from putting 
stuff beyond the left hand side of the article area, or above the bottom of the 
tabs? The main concern is preventing all those links from being hijacked. 
People using this for horrendous unaesthetic user pages is a secondary matter.
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-23 13:54:42 UTC
That's exactly my point.  See bug 9526 for a proposed solution.
Comment 12 Brion Vibber 2008-05-30 17:13:39 UTC
*** Bug 14346 has been marked as a duplicate of this bug. ***
Comment 13 Brion Vibber 2008-05-30 17:13:57 UTC
*** Bug 9526 has been marked as a duplicate of this bug. ***
Comment 14 Brion Vibber 2008-05-30 17:14:21 UTC
*** Bug 7303 has been marked as a duplicate of this bug. ***
Comment 15 Richard Jenkins 2008-05-30 17:22:42 UTC
May also be a good idea to blacklist the 'overflow' attrib. as well. See Bug 14346 for examples of disruption using this attribute.
Comment 16 Brion Vibber 2008-08-07 18:09:49 UTC
*** Bug 15066 has been marked as a duplicate of this bug. ***

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