Matthias Mullie has submitted this change and it was merged.
Change subject: Bug 43373 - CTRL+Click on "Feedback from my watched pages »"
should open the link in a new tab
......................................................................
Bug 43373 - CTRL+Click on "Feedback from my watched pages »" should open the
link in a new tab
Change-Id: Ifc81479b6e2be5c9f1aba5ba738a52d1ece7d8b9
---
M modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.track.js
1 file changed, 62 insertions(+), 49 deletions(-)
Approvals:
Matthias Mullie: Verified; Looks good to me, approved
jenkins-bot: Checked
diff --git a/modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.track.js
b/modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.track.js
index 283a7b3..ad127f0 100644
--- a/modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.track.js
+++ b/modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.track.js
@@ -148,65 +148,78 @@
}
/*
- * IE does not appear to support a way to simulate a real
event. Since we can
- * not resume an event nor trigger an exact new one, let's just
not stop this
- * one (for IE) - I'm aware that this may result in aborted
ClickTracking calls,
- * but correct UX behavior is more important
+ * In windows, ctrl key will usually open in new tab; osx is
command key.
+ * Shift key will open links in new window.
+ * If this is pressed, the link will fire in new tab, which is
ok, since
+ * the current page remains open and the ajax call. In this
case, let's
+ * not block the default behaviour & just let it open the new
tab - only
+ * block default behaviour if the ctrl/meta button is _not_
pressed.
*/
- if ( typeof e.target.fireEvent == 'undefined' ) {
- /**
- * $.trackActionWithInfo ends with a $.post to submit
the data to
- * ClickTracking API. We do not want any default
behavior to
- * interrupt that ajax call, so prevent any default
behavior (e.g.
- * redirect to a clicked link's href) until the call
has completed
+ if ( !e.ctrlKey && !e.metaKey && !e.shiftKey ) {
+ /*
+ * IE does not appear to support a way to simulate a
real event. Since we can
+ * not resume an event nor trigger an exact new one,
let's just not stop this
+ * one (for IE) - I'm aware that this may result in
aborted ClickTracking calls,
+ * but correct UX behaviour is more important
*/
- e.preventDefault();
- e.stopPropagation();
+ if ( typeof e.target.fireEvent == 'undefined' ) {
+ /**
+ * $.trackActionWithInfo ends with a $.post to
submit the data to
+ * ClickTracking API. We do not want any
default behaviour to
+ * interrupt that ajax call, so prevent any
default behaviour (e.g.
+ * redirect to a clicked link's href) until the
call has completed
+ */
+ e.preventDefault();
+ e.stopPropagation();
+ }
}
// submit call to ClickTracking API
$.aftTrack.track( e.data.trackingId )
.done( function () {
- if ( typeof e.target.dispatchEvent !=
'undefined' ) {
- /*
- * Multiple browsers support
dispatchEvent, though with
- * different behavior.
- * Opera (maybe other browsers as well)
supports the general
- * "Events" as parameter for
createEvent. Firefox (and maybe
- * others) need an exact e.g.
"MouseEvent" for mouse events.
- * Opera will know what to do based on
the first parameter
- * passed to initEvent (which is the
actual event to perform),
- * Firefox however will ignore this.
- * IE9 does not appear to do much
either way.
- * IE8 and lower do not even support
dispatchEvent.
- * I do want to use the general
"Events" though to keep this
- * code general-purpose.
- * If evt.eventPhase equals 0 (browsers
other than Opera), the
- * event will not properly be
triggered, in which case we fall
- * back to other methods.
- *
- * @see
https://developer.mozilla.org/en-US/docs/DOM/event.eventPhase
- */
- var evt = document.createEvent(
'Events' );
- evt.initEvent( e.type, e.bubbles,
e.cancelable );
- }
- if ( typeof evt != 'undefined' &&
evt.eventPhase > 0 ) {
- e.target.dispatchEvent( evt );
- } else {
- if ( typeof e.target.fireEvent !=
'undefined' ) {
+ // only resume event if link wasn't opened in
new tab/window
+ if ( !e.ctrlKey && !e.metaKey && !e.shiftKey ) {
+ if ( typeof e.target.dispatchEvent !=
'undefined' ) {
/*
- * IE-specific; IE does not
support <target>.<event>();
- * This will only fire attached
events, but will not simulate
- * a "real event" (as in:
triggering a click on a link will
- * not make the browser follow
the link)
+ * Multiple browsers support
dispatchEvent, though with
+ * different behaviour.
+ * Opera (maybe other browsers
as well) supports the general
+ * "Events" as parameter for
createEvent. Firefox (and maybe
+ * others) need an exact e.g.
"MouseEvent" for mouse events.
+ * Opera will know what to do
based on the first parameter
+ * passed to initEvent (which
is the actual event to perform),
+ * Firefox however will ignore
this.
+ * IE9 does not appear to do
much either way.
+ * IE8 and lower do not even
support dispatchEvent.
+ * I do want to use the general
"Events" though to keep this
+ * code general-purpose.
+ * If evt.eventPhase equals 0
(browsers other than Opera), the
+ * event will not properly be
triggered, in which case we fall
+ * back to other methods.
+ *
+ * @see
https://developer.mozilla.org/en-US/docs/DOM/event.eventPhase
*/
- e.target.fireEvent( 'on' +
e.type );
+ var evt = document.createEvent(
'Events' );
+ evt.initEvent( e.type,
e.bubbles, e.cancelable );
+ }
+ if ( typeof evt != 'undefined' &&
evt.eventPhase > 0 ) {
+ e.target.dispatchEvent( evt );
} else {
- /**
- * Firefox, Safari, Chrome &
possibly others simulate a "real
- * event" from this (Opera & IE
do not)
- */
- e.target[ e.type ]();
+ if ( typeof e.target.fireEvent
!= 'undefined' ) {
+ /*
+ * IE-specific; IE does
not support <target>.<event>();
+ * This will only fire
attached events, but will not simulate
+ * a "real event" (as
in: triggering a click on a link will
+ * not make the browser
follow the link)
+ */
+ e.target.fireEvent(
'on' + e.type );
+ } else {
+ /**
+ * Firefox, Safari,
Chrome & possibly others simulate a "real
+ * event" from this
(Opera & IE do not)
+ */
+ e.target[ e.type ]();
+ }
}
}
}
--
To view, visit https://gerrit.wikimedia.org/r/42541
To unsubscribe, visit https://gerrit.wikimedia.org/r/settings
Gerrit-MessageType: merged
Gerrit-Change-Id: Ifc81479b6e2be5c9f1aba5ba738a52d1ece7d8b9
Gerrit-PatchSet: 3
Gerrit-Project: mediawiki/extensions/ArticleFeedbackv5
Gerrit-Branch: master
Gerrit-Owner: Matthias Mullie <[email protected]>
Gerrit-Reviewer: Matmarex <[email protected]>
Gerrit-Reviewer: Matthias Mullie <[email protected]>
Gerrit-Reviewer: jenkins-bot
_______________________________________________
MediaWiki-commits mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-commits
