Several people complained that "Learn more on Wikimedia Commons"
is not clear: it can be interpreted as a link to the Commons
main page, the text does not suggest that the link will be related
to this specific file. The new wording tries to address this.
Change-Id: Ia605cc30c4ca57598f7cebdde60061800a10b6e7
It's important that when we generate the graphs based on
EventLogging data, we have a foolproof way to filter out
local runs that happened during development.
Change-Id: Ifc65d3b4bfb96946a8e8d59d080a6c5ee6552533
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/509
* Remove login since it's not longer needed
* Point to a new smaller test page instead of Lightbox_demo
which should make the tests run much faster
* Tweak selenium scroll workaround which seems to be speed-dependant
Change-Id: I247ae6a5044ecc93b6f3839f1b9ed955b488b5a7
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/475
- Runs combinations of cold/warm browser cache and average/large window size
- Sends events with EventLogging that will allow us to generate limn graphs
This should run separately from the other cucumber test we already
have. This one needs different environment variables because it needs
to run against production wikis instead of beta wikipedia
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/378
Change-Id: I53b521ca2759c493aae6fe6e59be8d448e0f15d7
The scrolling logic has broken specifically when navigating with the
back button (as opposed to pressing the "close" button). This change
aims to test that scenario.
Change-Id: Ibe31b319c882b7de2a84ae143652144093c50f1c
It turns out that cucumber/selenium will automatically scroll
to the element you want it to click on. As a result we have to do
the same in order for the assertion to be correct when coming back to
the article.
Change-Id: I7d3b6609cfe7cdae9c08a6d723d652ad1a6a7055
There used to be a CSS trick with the order we added things to the
page and removed them from it, but it doesn't seem possible anymore
with the new order of execution, with the overlay appearing
immediately and being taken care of inside bootstrap.
The main cause of the bug, however, was the hash reset happening
after the interface was closed.
Doing the scroll restore with jQuery.scrollTo is more future-proof
and testable in QUnit.
Additions were also made to the cucumber E2E test because QUnit
alone wouldn't have caught the hash issue.
This also cleans up custom events a little and reintroduces
pushState on browsers that support the history API.
Change-Id: I63187383b632a2e8793f05380c18db2713856865
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/439
Bug: 63892
With apologies to anyone who gets a hundred merge conflicts
because of this :)
We had several different prefix styles (mlb-, mw-mlb-, mw-mmv-,
mw-mmv-mmv-, a few unprefixed), which was getting annoying,
and will be confusing to wiki editors who are trying to figure out
where a given style comes from. Such changes are better done before
going live because it breaks all local CSS tweaks on the wiki,
so I am renaming things now (also removing some stuff which wasnt
used anywhere).
Change-Id: I00447a25f0028e234169c6db941bedc99622eb8d
All Jenkins jobs will fail until this commit is merged:
https://wmf.ci.cloudbees.com/view/mv/
Bug: 61778
Change-Id: I5fb37946bbb15cb1b70045f85aa11ba48ecd2260
After lots of experimenting with Wireshark and
current Chrome + Firefox on Ubuntu 13.10, this is my
current understanding of the caching when preloading images
with AJAX requests:
* on Chrome, the image request always comes from browser cache
* Firefox makes two separate requests by default
* Firefox with img.crossOrigin = 'anonymous' makes two separate
requests, but the second one is a 304 (does not load the
image twice)
* when the image has already been cached by the browser (but not in
this session), Chrome skips both requests; Firefox skips the AJAX
request, but sends the normal one, and it returns with 304.
"wish I knew this when I started" things:
* the Chrome DevTools has an option to disable cache. When this is
enabled, requests in the same document context still come from
cache (so if I load the page, fire an AJAX request, then without
reloading the page, fire an AJAX request to the same URL, then the
second request will be cached), but an AJAX request - image request
pair is an exception from this.
* when using Ctrl-F5 in Firefox, requests on that page will never hit
the cache (even AJAX request fired after user activity; even if
two identical requests follow each other). When using clear cache
+ normal reload, this is not the case.
* if the image does not have an Allow-Origin header and is loaded
with crossOrigin=true, Firefox will refuse to load it. Chrome will
log an error in the console saying it refused to load it, but will
actually load it.
* Wireshark rocks.
Pushed some tech debt (browser + domain whitelist) into other tickets:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/232https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d.
63021d0b0e.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
As suggested by Chrismcmahon, I confirmed that there is no need
to fire the onfocus event. We also remove the convenient functions
around this logic.
Change-Id: I00ce04c758e496f76bd5c2a43ad933c952acc5fb
The first version of the e2e tests just checked the presence
of some DOM sections. This 2d version actually verifies the
values for most of the components in the viewer.
Change-Id: Iabfd544f05182e86a16cf6bda162bb0abc5cf260
We are using data:URIs to measure performace. This
change broke e2e tests that were trying to match plain urls.
Change-Id: I8220801472cde595dd6651ef2796468eba484071
