-
-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hide article list on prefix blur or on Esc #499
Conversation
Hmm, Travis seems to have fallen over on Edge, but not on any other browser. I have tested this extensively on Edge 44, and the code only affects the UI, not the content in any way. I wonder if this is a transitory issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're telepathic! I just implemented that today and was waiting to get this PR approved / merged before posting the code as a new PR. |
Regarding the UI tests that fail on Edge 40 and 42, I tried to restart Travis several times, but they still fail. |
Well, the issue on Edge UI tests is not obvious. |
Tests still failing on Edge 40. Edge 40 is pretty much only still used on Windows Mobile, and that platform is no longer being developed (though still supported with bugfixes for a while longer). I test manually for Windows Mobile when I port things to Kiwix JS Windows. So far I haven't found incompatibilities, but haven't tested this latest code there yet. If there were an incompatibility, I'd work around it there. I'd say it's pretty safe to drop tests for Edge 40. |
OK, so I'll remove the UI tests for Edge 40 (but keep the unit tests on it).
|
@mossroy I've compiled a test version of Kiwix JS Windows that uses this code for Windows Mobile (Edge 40), and have successfully run it there. So yes, it's safe to remove old versions. I have no idea why the tests are failing... |
I've kept the beginning of UI tests on Edge (all versions), because they never failed (as far as I know) : opening the ZIM file and searching for articles are still covered. It's still better than no UI test at all. I had to disable latest Edge, because I did not find an easy way to know its version, which is needed to distinguish Edge 44 (currently latest, which needs to disable some tests), and EdgeChromium (future latest, on which we should try to run all tests). When EdgeChromium will be released, and available on SauceLabs, I'll re-enable latest Edge |
OK, sounds good! Shall I go ahead and squash/merge this? |
And if I merge, should I keep two commits, one for this issue and one for the unit tests? |
Yes, you can go ahead. |
02b87e0
to
4c79abe
Compare
The unit tests were implicitly disabled after kiwix#499 due to an issue with the UI tests found on an older Edge version that was the default "edge" version on SauceLabs in May 2019 (not sure which version that was, the last pre-Chromium Edge version was 44, which was passing, so perhaps SauceLabs defaulted to a beta release or a much older version like 15-18?) Now that Edge uses Chromium, try re-enabling the unit tests there. Fixes kiwix#502.
The tests were disabled after #499 due to an issue with the Edge version that was the default "edge" on SauceLabs in May 2019 (not sure which version that was, the last pre-Chromium Edge version was 44, which was passing, so perhaps SauceLabs defaulted to a beta release, or used a much older version like 15-18?) Now that Edge uses Chromium, try re-enabling the tests. Fixes #502.
The tests were disabled after #499 due to an issue with the Edge version that was the default "edge" on SauceLabs in May 2019 (not sure which version that was, the last pre-Chromium Edge version was 44, which was passing, so perhaps SauceLabs defaulted to a beta release, or used a much older version like 15-18?) Now that Edge uses Chromium, try re-enabling the tests. Fixes #502.
* workflows: Rename "CI" to "Release" Rename this to make space for a separate "CI" workflow that will run continuous integration and testing jobs for commits and PRs. * workflows: add CI workflow for unit tests and support running locally * Load qunit package from npm, this is the start of a larger transition. ref at #554. * Update QUnit from 2.3 to 2.13. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on fragile and unsupported DOM scraping to collect test results, which breaks between framework versions. ref #660. - severely limits debugging information for failing tests. - cannot easily be reproduced or debugged locally from the command-line as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server. People usually do not have this installed and it's non-trivial to set up and keep working in the long term, and across multiple different software projects. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref #528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes #653. * Re-enable unit and UI tests in latest Edge The tests were disabled after #499 due to an issue with the Edge version that was the default "edge" on SauceLabs in May 2019 (not sure which version that was, the last pre-Chromium Edge version was 44, which was passing, so perhaps SauceLabs defaulted to a beta release, or used a much older version like 15-18?) Now that Edge uses Chromium, try re-enabling the tests. Fixes #502.
This fixes #39 and the regression in #442.
The behaviour is as follows:
In the process, testing on FFOS where the on-screen-keyboard causes drastic screen resizes, I discovered an obsolete value still being used, erroneously in the
resizeIframe()
function. Since we now floatarticleListWithHeader
over the article, we shouldn't subtract its height from thewindow.outerHeigh
. It causes a drastically shortened screen otherwise.I have coded this with jQuery for the sake of consistency with surrounding code.
Tested in Edge 44, Edge 75, FFOS.