What MultiMediaViewer does is re-using the small thumbnail <img> that
is already present on the page, cloning it, blowing the size up, and
using it as a "placeholder thumbnail". The moment the bigger image
finished loading, it replaces the placeholder.
The issue here is that the cloning includes class names like the
<img class="thumbimage"> on every [[File:…|thumb]] image. This shows a
gray border. The cloned DOM node in MultiMediaViewer shows this gray
border around the placeholder for a short time. This can be distracting.
Change-Id: Ie83427fab478b6568731b9a0b1f7dbbcc6d5b0fb
These modules are deprecated and will be removed, see parent task for
details and deprecation information.
Bug: T223284
Change-Id: I2532e20659a59cdd036a7d8ad5a040ae136848f5
Sauce labs removed support for OSX 10.9, so we've seen failures in the
browser tests for a while apparently.
The generic "macos" should just work, and is sufficient for our testing
needs.
Bug: T214389
Change-Id: I01c1e9e03dc5b658aa3e2b3ee6a7b5f503488f97
* Deletes the mmv.model.EmbedFileInfo class file and its test file
* Updates the extension.json and MultimediaViewerHooks.php files to reflect
these deletions (by removing entries from dependency lists)
* Refactors all instances of `new mmv.model.EmbedFileInfo()` to instead use a
POJO with appropriate properties. Conditional assignment is used for the
caption and alt properties if there is any chance they won't be available, to
keep from adding props with falsy values.
* Refactors JSDoc method annotations so that `@param` tags expecting an
EmbedFileInfo instance now expect an object; relevant properties of this
object and their types have been added to the method annotations as well.
Bug: T77320
Change-Id: Ie9f5f24136f4b73000259685474ce4d765a3ccd3
When an svg file is requested, returns the 1024px file and displays at
max possible size
Bug: T71237
Change-Id: I797794d1f9b1aa66cbb9bd9fec57274554292fb1
As we already allow visual markup in captions, I see no reason to not
whitelist sup and sub. These elements are even allowed in the
displaytitle whitelist for articles, so seems appropriate to have them
for media captions as well.
Bug: T186844
Change-Id: I4339ee85d139301770a4e15650c9dc0d64c136cd
Media Viewer tries to detect the file name from the thumbnail name.
That can break for the main image of a file page, which is normally
a preview (ie. a normal thumbnail) but for unhandled types it can
be some asset (such as a PDF icon).
Bug: T137477
Change-Id: Ie6b23d7ef213087971b320460129910f2efd248e
Test failure from jenkins:
https://integration.wikimedia.org/ci/job/mwext-mw-selenium-jessie/6608/console
Background: # features/mmv.download.feature:4
Given I am viewing an image using MMV # features/step_definitions/mmv_steps.rb:21
expected "https://creativecommons.org/licenses/by-sa/3.0" to match /^http:\/\/creativecommons.org\/licenses\/by-sa\/3.0$/
Diff:
@@ -1,2 +1,2 @@
-/^http:\/\/creativecommons.org\/licenses\/by-sa\/3.0$/
+"https://creativecommons.org/licenses/by-sa/3.0"
(RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/mmv_steps.rb:126:in `check_elements_in_viewer_for_image2'
./features/step_definitions/mmv_steps.rb:73:in `block (2 levels) in <top (required)>'
./features/step_definitions/mmv_steps.rb:70:in `/^the image metadata and the image itself should be there$/'
./features/step_definitions/mmv_steps.rb:25:in `/^I am viewing an image using MMV$/'
features/mmv.download.feature:5:in `Given I am viewing an image using MMV'
Scenario: Download menu can be opened # features/mmv.download.feature:7
When I click the download icon # features/step_definitions/mmv_download_steps.rb:8
Then the download menu should appear # features/step_definitions/mmv_download_steps.rb:54
Change-Id: I6feda65ca8ff2bc8f790eaaac8f63e1feafcbdfd
This is an old library that is broken in Chrome 61.
Rather than updating it we can just use $(window).scrollTop/Left
which works in all the browsers we currently support.
Fix MPSP.toggle to return a promise, instead of a deferred
(although this return value is not used yet).
Bug: T173618
Change-Id: Iaec56debbb808bd95cf65c1ebfe22bdf0116da68
* Removed deprecated testCount, which is no longer supported in this way.
It's only useful when wanting to explicitly expect 0 assertions (normally
considered an error).
* Replaced use of testCount = 0, with assert.expect( 0 ).
Change-Id: I8fe82032d3af2a1ad2ed7febdb90a95d56dd3fc4
Meanwhile I also updated a few places where a non-string was
passed to/expected from localStorage - this could’ve led to
inconsistencies because localStorage stringifies everything.
And I also removed CP.canSetMediaViewerEnabledOnClick, which
was no longer used anywhere except for a test case.
Bug: T137777
Change-Id: I21ad4ba15ca751bb03e5e2c523d09a45c0444ccf
This heavily relied on deferreds getting resolved synchroneously,
which (for .then) is no longer the case with jQuery 3.
There's also a difference in how chained .then's get resolved,
and $.when no longer propagates notify().
The changes in here are basically:
* fix use of $.when, manually passing along notify()
* use .then in some places, instead of .done, .fail, .progress
* fix progress bar hiding in setupProgressBar, which assumed sync
* fixed tests, mostly by using fake timers to give async stuff a
chance to execute
Bug: T164473
Change-Id: Ib51ddd8bc6254a477861588fb16f57565353afe1
This heavily relied on deferreds getting resolved synchroneously,
which (for .then) is no longer the case with jQuery 3.
There's also a difference in how chained .then's get resolved.
These tests did not wait for the deferreds to get resolved async,
so that had to change. Worse even: some functionality was tested
by assuming a handler would not be called (= the test in that
handler would not be called), which didn't make the test run,
because we never even waited for it to be called.
The changes in here are basically:
* make mmv.bootstrap.js correctly use .then instead of .done & fail
* let mmw.bootstrap.test.js tests wait for unresolved async promises
* check call counts instead of running tests inside of callbacks
* limit use of fake timer to the 1 test that needs it (it interferes
with async, which otherwise don't get resolved)
Bug: T164473
Change-Id: I3ca4f786890ad1646f71fe336afdb61e5c3b01c7
* Buttons are semantically better.
* Neither <div> nor <button> elements can have the 'alt' attribute
so switching to 'title' instead.
Reverts parts of I6ea62124018b1a0ec5110bb500f690cb2368f102.
Bug: T58471
Change-Id: I991b40d3387f8d6dd7cdad8ccc5cc9660b9f139a
Previously, the clickable text in the generated HTML credit lines
was the entire link to the article. This is shortened to a localized
version of "Link".
Bug: T119686
Change-Id: I708f65a85bfa26c264cdd06a265096027266240c
selenium* jobs are a new way of running Ruby based Selenium tests. The
jobs are triggered daily.
Bug: T128190
Change-Id: If0e6b61c9e3d52005d1851ca49ef65babd002919
Some of the code encountered accessed mw.config directly,
I cleaned that up by migrating to mmv.Config, which is an
abstraction added to avoid peeking at mw.config directly.
Bug: T132064
Change-Id: I2a95ba703e6c7f46296f8e435bceec769dceebf9
The browser test job uses 'www.mediawiki.org' to hit the API which is
then passed to cucumber for tag filter.
Update the scenario tag to match the canonical URL.
Bug: T128079
Change-Id: I68217b3e9867b768ccbba24bbffaa431c1c3035f
The job was failing with `301 Moved Permanently`. The problem was that
`mediawiki_url` was not `https` and was missing `www`.
Bug: T128079
Change-Id: I4f142c4ed17826b1e4051846395940e139e47689
We used to rely on the env variable BROWSER_USERAGENT for tests
requiring a customer user agent. 2c3ac55a6 got rid of it in favor of
loading the :browser_useragent from environments.yml where it has not
been set. That in turns caused tests to fail with:
"missing configuration for browser_useragent"
Set browser_useragent to 'test-user-agent' in the environments.yml
Also drop unused test2 env and add mediawiki-org
Bug: T128064
Change-Id: I720d590505dd5e30c6e9435de456563b8d36f9ea
Additional changes:
* Add a step to check JS has loaded
* Update selector to work on non-vagrant instances
Bug: T113620
Change-Id: Ib7579a43adc37b6e4add8b0ab75f99b6ab994bb6
Drop the title and site name. Use a shortened URL
created using the pageID for the curid query parameter.
Add pageID property to mmv.model.Image, using value already
fetched from an existing API request.
Bug: T119686
Depends-On: I0f00b986e6095bdb9b8d6af6fbc5b01995227e02
Change-Id: I9189f00bfbf7639974d66cf1921773855a77a865
On not-MMV -> not-MMV hash changes the bootstrap class has set
up and immediately torn down the overlay. Besides slowing things
down, this broke TOC navigation on Chrome in an ugly way.
Add a special case to skip the overlay loading when the new hash
does not contain #/media. This is a quick-and-dirty fix; the whole
loading and hash handling could use a rewrite.
Bug: T119854
Change-Id: I5494903dfe778e533773ff142fdf756475c2df32
Having many modules makes the startup module in the head
unnecessarily longer. Things should only be in their own
module if they're going to be loaded on demand on their
own or are a shared dependency of separate modules that
are.
This change brings down the amount of modules declared by
Media Viewer from 53 to 8. The ones that remain are
mostly things loaded on demand.
Bug: T103706
Change-Id: I5b0d29209599285b93217e96def818e641646c73
It decreases the likelihood of Varnish hits and is only 11% smaller on
average in file weight than the 800 bucket.
Bug: T102870
Change-Id: I8611791a192fa7b0e638ccfc886733b75bf30aed
These two tests fail on my local machine. I am making the two
assertions independent from
a) the order of HTML attributes (the test should not care about
the order, only if the attributes are there or not)
b) the message (both messages are possible and valid, the question
which message should appear is not part of that specific test).
Change-Id: I69b4793d365d3afebb869c787316e4242cb15b25