Apparently three wrongs make a right: hiding the overlay still worked.
* '#pt-notifications a' click event handler was not correctly checking
for events comig from inside the overlay due to a missing dot before
class name
* But if it were correctly checking, it would not be hiding the
overlay pokey (just its body) due to a copy-paste error
* Instead the clicks were handled by the 'body' click event handler,
which did not correctly check for events coming from
'#pt-notifications a'
I made things right again. The user-facing behavior is the same.
Change-Id: I02aba0e25ba4d81b234b327f120e0e2ff13d117c
Otherwise a new copy will be created every time the user opens and closes
the popup, and jQuery will hold on to each one forever (because it has
events bound), leaking a minuscule amount of memory.
Change-Id: I70c713be839f826fc27d07b04260c166f9052020
Core styles for Monobook include high-specificity background: transparent;
rule for #p-personal li a, we need to match it to set our background.
Also change hover behavior: switch to a deeper orange instead of
default white, similarly to how the badge already behaves.
Partially reverts I682182fe.
Bug: 56214
Change-Id: I9f343264c395ecf09c1e34e03d208ec2119fb622
Follows-up 383a818.
* There is no need for the additional element ("a") or
descendant ("#pt-mytalk") selector.
It isn't overrriding anything, only hardcodes details that make
it harder to maintain or extend this stylesheet. For example,
there is a gadget that makes user messages green instead of
orange, it now was required to hardcode the "#pt-mytalk a" part
of the selector eventhough those are subject to change.
Separation of concerns.
* Cache/reuse the jQuery object instead of executing the same
query to the document, again. It also avoids a potential bug
where the second query matches different elements (e.g. after
appending alertMessage, there could potentially be an additional
nested anchor link; there isn't now though, as the message is
plain text).
* Add comment about weird echoNewMsgAlertDisplayed variable.
Change-Id: I682182fe15a868969f25fa5bfe2412e2a6f3dddf
* In some languages like persian, the number 0 is represented as '.', we can't compare
'.' with either 0 or '0' to detect the no-notification status of the badge
* The markread API doesn't respect uselang param, it would return 0 instead of . in a url with uselang=fa
Note: we need to provide raw and formatted count in the API since client side javascript
doesn't provide fancy function like $wgLang->formatNum()
bug: 54575
Change-Id: I0a49828253ec346ed27c5b9a976f8bdff4e1fa90
Removing unused functions and declaring correct dependencies.
Targetting to desktop and mobile so it can be used by both.
Also removing dismiss-related code from the formatter.
Change-Id: Icccce64cfb3c564ab468a93ccdba9c5a61687fd5
Also making sure that footer has some amount of separation from
the notification title even if there is no payload.
Change-Id: I85a1a7989539044a0b0b53e76e70ddee9bb7165c
The space after colon on this line is actually a non-breaking space
( ), which is not allowed in this place according to CSS syntax.
Therefore all browsers ignored this rule (logging an error like
"Invalid CSS property value") and the shadow was never shown.
We could fix the rule instead, but I'm pretty sure users are used to
this by now, and in my opinion it looks better without shadow.
Bug: 53490
Change-Id: I1fd508d2059bec5cd79a6dcdce8dc9be6e6d4229
We want the notifications in the flyout to behave just like links,
including standard middle-click and Ctrl-click behavior. The simplest
way to do that would be to actually make them links - but the area can
contain a few other links, so we can't do that and have to resort to
ugly hacks.
Or do we?
Turns out that while browsers won't accept HTML containing nested <a>
tags[1], such a structure is valid XHTML, and it's possible to create
such structure in HTML mode using DOM manipulation. It works like one
would expect: the entire thing is clickable, but inner <a> tags' hrefs
override outer ones.
Firefox even had a request to make that work[2] which was happily
fulfilled.
Tested the basic case [see below] on Firefox 22, Opera 12, Opera 15
(which uses the Blink engine like Chrome), IE 8 and IE 6 and it works
the same on all of them. Tested the XHTML variant [see below] on all
of the above except for the IEs which don't grok XHTML and it exhibits
the same behavior.
[1] Simple test: $('<div>1<a>2<a>3</a>4</a>5</div>').html() is
"1<a>2</a><a>3</a>45", not actually "1<a>2<a>3</a>4</a>5" like one
might expect.
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=331959
----
The test cases used are below. When trying out the XHTML one make sure
that the browser uses application/xhtml+xml MIME type; saving the file
with .xhtml extension should be enough.
XHTML:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
<div>1<a href="http://google.com/">2<a href="http://example.com/">3</a>4</a>5</div>
</body>
</html>
HTML:
<!DOCTYPE html>
<html>
<body>
<script type="text/javascript">
var div = document.createElement('div');
var a1 = document.createElement('a');
a1.href = "http://google.com/";
var a2 = document.createElement('a');
a2.href = "http://example.com/";
div.appendChild( document.createTextNode('1') );
div.appendChild( a1 );
a1.appendChild( document.createTextNode('2') );
a1.appendChild( a2 );
a2.appendChild( document.createTextNode('3') );
a1.appendChild( document.createTextNode('4') );
div.appendChild( document.createTextNode('5') );
document.body.appendChild(div);
</script>
</body>
</html>
----
Bug: 52319
Change-Id: I311eca70f025ce92129c828cd88f96686b7cff72
Out of the default MW skins these only seem to affect CologneBlue.
* Reset padding and list-style-image on ul#mw-echo-special-container
ourselves, do not rely on the skin doing it
* Use transparent background on .mw-echo-notification (and
semi-transparent black on hover) instead of solid white and
light grey to accomodate colored skin backgrounds
Change-Id: I2c178627e4dbe889c4958afc41e4969aaa45a717
wgUserNewMsgRevisionId is null with only one revision and that revision is
not viewed, this makes it not reliable for determining if there is new
message. We just switch to check against $user->getNewtalk() instead.
We can still use wgUserNewMsgRevisionId to generate diff links if desired
Change-Id: I4cf50a944aada03151bd17f3610bd59b3bfb2bf2
separate into multiple ul elements with headings dividing them
This removes need for unnecessary styling rules in mobile web
Change-Id: I8acaef726ea0cc639054cf36d6c3649c7ab25bee
* Add missing spaces after 'function'
* Remove underscores from identifiers
* Don't use typeof for undefined with local variables and object properties
* API ok/err is deprecated since MediaWiki 1.20 (< 1.22-alpha), use .done and .fail
Change-Id: I5ca3403ee263a0c3e6709618e48e896340952337
