* Messagebox is now private to Html class to discourage unconventional
usages
* Tests are added for all three helper methods added in
4e7021a231
Bug: T166915
Change-Id: I1c3e4131b2439c0f4fb94ad4e616a909b52d6b78
We blacklisted them in 2010. Modern browsers support them fairly well,
and it doesn't seem to conflict with any of our code.
I tested this with SecurePoll poll creation form, which contains an
astonishingly wide range of form controls and validation options.
Change-Id: I08244addcf9b6eb96137895f28e7b750914fef5c
Use HTTPS instead of HTTP where the HTTP link is a redirect to the HTTPS link.
Also update some defect links.
Change-Id: Ic3a5eac910d098ed5c2a21e9f47c9b6ee06b2643
It looks like there is something missing after the last statement
Also remove some other empty lines at begin of functions, ifs or loops
while at these files
Change-Id: Ib00b5cfd31ca4dcd0c32ce33754d3c80bae70641
`<command>` is nowhere to be found in current HTML5 specification.
Scarce documentation on the internet hints that it has been removed.
Change-Id: I2a704194c7e8f8ca307f9d97c7f47a47cfaf00a6
Follows-up ee4d5c6ee ("Remove support for $wgWellFormedXml = false")
Remove now-redundant duplicate tests that were previously there
to test the same thing again with $wgWellFormedXml set to false.
Change-Id: I91623a8c10e5108ffae13f67328aece2cf33c719
tl;dr: Having unnessary complexity in security critical code is bad.
* Extra options add extra complexity and maintenance burden
** Thus we should only have one html output mode. well formed = false
was already vetoed in T52040, so lets go with WellFormed=true.
* Options which are used by very few people tend to get tested less
* Escaping is an area of code where we should be very conservative
* Having escaping rules depend on making assumptions about which
characters various browsers consider "whitespace" is scary
* $wgWellFormedXml=false has had a negative security impact in the
past (Usually not directly its fault, but has made other bugs
more exploitable)
* Saving a couple bytes (even less bytes after gzip taken into
account) is really not worth it in this context (imho).
Change-Id: I5c922e0980d3f9eb39adb5bb5833e158afda42ed
It seems both of these tests assertions all expect
this to be false.
Ic675e92d8dd8f11fa67914d2ce1dc00a379106ca
ended up discovering these issues somehow
with these tests suddenly starting to fail.
Change-Id: I9d2d3c18d1c9640e2ff04d6fd4296abb86e26877
* Remove trailing space in self-closing tag.
Brings parserTest output of Parser and Parsoid closer together.
* Remove various line breaks at begin and end of script contents.
* Remove FILTER_NOMIN from makeConfigSetScript() output.
This isn't part of any user- or page-dependent module and not minified.
And Xml::encodeJsCall already ensures compact output for prod mode.
Bug: T127328
Change-Id: I85a5a59fd0955c1a112e8b24b933f0d9e983a156
Removed redundant set up in these classes (same as their paren
class MediaWikiLangTestCase does already).
* BlockTest
* ExportTest
* MWTimestampTest
* TitlePermissionTest
Change-Id: I28d18cb797bb249981727b02dffce4f0d8682b02
$wgLogoHD is meant to contain high-density alternatives for $wgLogo, but its
keys include the trailing 'x' (e.g., '1.5x'), making it unusable with
Html::srcSet(). Fix that by normalizing all density values to have a
single trailing 'x'.
Change-Id: I62cc3a9e4aeff3a7cb102de2965b8b40fd106c37
We were always adding it previously, which seemed harmless since
'mediawiki.ui.input' RL module, providing the styling, was only loaded
if $wgUseMediaWikiUIEverywhere was true… unless someone loaded it
manually to have specific input fields styled. Whoops.
There are a lot more unconditional additions like this in tons of
places in the code, and someone should check whether each one is
intentional or not, but probably no one will. Oh well.
Bug: T92496
Change-Id: I5e91a3852a76ebbbfe64485bccb4c30ddee28b66
This provides better mobile experiences on various pages
and a more consistent UI across both mobile and desktop.
It does this in two ways.
1) Forces HTMLForms to not use table based layouts so as
not to interfere with responsive nature of mediawiki ui elements
2) Applies MediaWiki.UI classes to most pages
If a page is created via Xml or Html classes it will use mediawiki ui
Where possible I've added classes unconditionally, but for cases of buttons
this is behind the $wgUseMediaWikiUIEverywhere global since button styling is
enabled on pages by default and for checkboxes since it is changes HTML markup.
3) Adds all MediaWiki.UI styles to pages which can use it
When enabled:
* Apply these styles to all pages which use HTMLForms
* Apply to EditPage
* Apply to anything that uses certain elements outputted by the
Xml or HTML helper classes
* Apply to History page
* Apply to protection page
* Apply to move page
* Apply to deletion page
Currently kept behind a global to allow us time to finetune
existing elements. After further testing we will look to kill the
globals and make mediawiki.ui the default
See: I430c0fbb79d2a33bb828b2427bda0ee01115d73f
Change-Id: I47db5eab4569514d039261d11b6dedb0eeae17b5
Migrated some convenience functions from the Xml
class to Html so they can be used. Only added
functions that acted as more than just a wrapper
for another function.
Change-Id: I4cc5876d4be6e04ec554444242cc049a3cff0f58
Previously the behavior was more or less undefined for most attributes
except for the ones in $spaceSeparatedListAttributes (currently 'class',
'accesskey' and 'rel'). If an other attribute is set to an array (no
matter what it contains) the method produces broken HTML like
'key=' and only triggers a warning if error_reporting is enabled. If
error_reporting is not enabled a developer may overlook this.
To clarify: The method always *ALLOWS* array values. This is *NOT*
about unexpected types in the call signature but unexpected
combinations of nested values. These combinations are already
checked in the method but the check was incomplete.
I considered several solutions:
* Simply use the first array element. But we can't know if the first
element is what the caller expected.
* Silently drop all arrays if the attribute doesn't allow lists. This
is close to the current behavior of always returning 'key=' but is a
breaking change for boolean attributes like 'checked' and 'selected'.
Browsers accept the current 'checked=' as true while omiting the
attribute means false.
Choosing to always throw an exception. As above, this is a
breaking change in some cases.
Change-Id: Id5fcbdef2696d0a81a91d54338939ee678475ca3
* $wgHtml5 = false; is now ignored completely.
* $wgDocType and $wgDTD have been removed.
* $wgXhtmlDefaultNamespace is now ignored.
* XHTML5 will be output if $wgMimeType is set to an XML mime type (according to HTML5's rules).
* For backwards compatibility with extensions $wgHtml5 and $wgXhtmlDefaultNamespace are set
in Setup.php but depending on them is deprecated.
Change-Id: Iad9634e2ee420b5a3bbffe550421fde4fa1819b0
Change some tests to use setMwGlobals to have restoring of globals after
the test.
This also removes some save/restore code, which is not needed, due to
the automatically restoring on tearDown with setMwGlobals.
Change-Id: I8d2ac9f6cc14f0bd4ee8eb851c09f2e71babc6e0
The default value for "step" is "1" which effectively bans any decimal
number from being entered into an 'type="number"' field and makes
HTMLFloatField unusable.
Change-Id: I103fd4047814a7fb0dfdc174f36badd5b660b7a4
According to standard the default type for <button> elements is "submit". Depending on compatibility mode IE might use "button", instead.
To work around the IE bug this patch forces the standard "submit", if nothing is specified explicitly.
See remarks on http://msdn.microsoft.com/en-us/library/ie/ms535211%28v=vs.85%29.aspx :
-----
The default value of the type attribute depends on the current document compatibility mode. The default value is submit. In other compatibility modes the default value is button.
...
Windows Internet Explorer 8 and later. The default value of the type attribute depends on the current document compatibility mode. In IE8 Standards mode, the default value is submit.
In other compatibility modes and earlier versions of Windows Internet Explorer, the default value is button.
-----
Change-Id: I3b97a8cac74bbfca63699dfcbf1cc5e9a2cef193
The HTML and XML test now set the globals they depend on
(instead of relying on the default settings).
Tests for the "other" scenarios still exist, globals are
overridden inline. They are automatically restored after each
test## function by PHPUnit from MediaWikiTestCase::tearDown.
Also fixed 2 other problems with the test suite:
* HtmlTest::testDropDefaults forgot to pass
$message to the assertion from the provider ($case[3]).
* The data provider for HtmlTest::testDropDefaults was calling
Html::element directly (instead of calling it within the test)
which is problematic because data providers are expected to be
static. PHPUnit calls them outside the setUp/tearDown flow.
(also fixed the function to be public static, as PHPUnit
expects).
That last one was crucial to make the test still pass correctly.
Updated the expected strings to what they are with these
fixed non-leakage settings.
Took wgHtml5 without xmlform as default. And added tests
for variations where it made sense.
Change-Id: Iccf6ea81f4bc2639273ab2ad101c58788ee49d45
This closely match Html::dropDefaults() logic and hopefully test out
all default dropping.
Introduce a test case that match a failure in f34547ab where attribute
default values passed in an array are not cleaned up.
Change-Id: If8d16b066015ed1bcaf38408511ac3713eaa6540
The default value for value="" on <input> elements is not always an
empty string.
In particular the default value for type="radio" is "on" and by
stripping value="" out of the attributes a "" becomes "on" and our
cleanup code ends up breaking forms.
Change-Id: Ibe5a3be3f45a2f93ef95dbe42729b8f8c94a41cb
HTML5 introduced new types for the input element. For some reasons we
never added them to Html::openElement which would thus strip them even
in HTML5 mode.
The issue is:
$wgHtml5 = true;
Html::element( 'input', array( 'type' => 'color' );
# -> "<input />"
With this patch, we returns: <input type="color" />
Change-Id: I7de373635d0eb47f788d1d664c3a913c8801efd6
* Remove default id/name attributes
* Remove now redundant tests introduced in r110274
* Add tests to make sure label has no 'for' attribute when label isn't null but name/id are unset
* Update tests to not include id="" and name="" when calling with no arguments
* Updating calls to add name/id if needed, and while at it remove useless 'null' params
* Context:
-- Introduced in r109990, r111376, r111315
-- No callers exist that assume these defaults. Forcing an ID that should be unique is annoying and redundant. The name used in the query when submitting a form should be mentioned in the same file where it is used from the submission, never assume what name="" is from unrelated code
-- Same for ID, this is often used in CSS or JavaScript, shouldn't be assumed. (It should be simple to but two simple namespace selectors on a page without getting DOM conflicts)
