Javascript in HTML captures all keys

Issue #474 closed
Vlastimil Zíma created an issue

There is only a handful of hotkeys defined in HTML, but the JS captures any key pressed, including navigation keys, which makes the HTML output practically unusable.

I experience the bug in 3.7.1, 4.0.3 and 4.1b2.

Comments (16)

  1. Ned Batchelder repo owner

    Can you tell me more about your environment and what keys you are trying to use? I'm using Firefox on a Mac, and all of the menu shortcuts continue to work for me.

  2. Vlastimil Zíma reporter

    I'm using Firefox on Debian and I tried Chromium as well. I reproduced the bug on at least 3 different stations, but all Debian.

    I captures all the keys. It's especially annoying for arrows, Shift, Ctrl, Alt, PageUp, PageDown etc. when I move around.

  3. Vlastimil Zíma reporter

    I removed library libjs-jquery-hotkeys in version 0~20130707+git2d51e3a9+dfsg-2. That helped. But I don't know if the bug is in the library or in coverage.

  4. Valentin Lorentz

    Same problem here, with Firefox 44 and Chromium 49 on Debian Jessie. coverage 4.0.3.

    Removing the file htmlcov/jquery.hotkeys.js did not change anything.

  5. Vlastimil Zíma reporter

    @ProgVal: I have removed whole libjs-jquery-hotkeys package from system. Newly generated html outputs are fine.

    The only problem I encountered is that in such case coverage returns non-zero exit code which complicates scripts.

  6. Ned Batchelder repo owner

    @ziima Can you explain what you mean by "I have removed whole libjs-jquery-hotkeys package from system"? Is that something coverage.py provided? Or something the operating system provided?

  7. Vlastimil Zíma reporter

    The coverage package in Debian (and most likely Ubuntu) is by default installed with libjs-jquery-hotkeys library. The hotkeys library is provided by the system, but if it isn't available, coverage html report exits with non-zero exit code, so coverage apparently requires that library.

    For details of debian package see https://packages.debian.org/stretch/python-coverage

  8. Ben Finney

    A good solution would be for Coverage.py to degrade gracefully in the absence of each of the JavaScript libraries: if one isn't present, the whole continues to work, just absent the features of that library.

  9. Loic Dachary

    It looks like an issue that should be filed against https://packages.debian.org/stretch/python-coverage. However, the difference between the jquery.hotkeys.js file provided by the libjs-jquery-hotkeys package and one provided by coverage.py does not explain why it would cause this problem.

    --- /tmp/libjs-jquery-hotkeys-0~20130707+git2d51e3a9+dfsg/jquery.hotkeys.js 2016-12-14 23:42:26.000000000 +0100
    +++ /home/loic/software/coveragepy/issue-474/coverage.py/coverage/htmlfiles/jquery.hotkeys.js   2016-12-14 20:13:35.576077233 +0100
    @@ -22,8 +22,7 @@
                96: "0", 97: "1", 98: "2", 99: "3", 100: "4", 101: "5", 102: "6", 103: "7",
                104: "8", 105: "9", 106: "*", 107: "+", 109: "-", 110: ".", 111 : "/", 
                112: "f1", 113: "f2", 114: "f3", 115: "f4", 116: "f5", 117: "f6", 118: "f7", 119: "f8", 
    -           120: "f9", 121: "f10", 122: "f11", 123: "f12", 144: "numlock", 145: "scroll", 188: ",", 190: ".",
    -           191: "/", 224: "meta"
    +           120: "f9", 121: "f10", 122: "f11", 123: "f12", 144: "numlock", 145: "scroll", 191: "/", 224: "meta"
            },
    
            shiftNums: {
    @@ -45,7 +44,7 @@
            handleObj.handler = function( event ) {
                // Don't fire in text-accepting inputs that we didn't directly bind to
                if ( this !== event.target && (/textarea|select/i.test( event.target.nodeName ) ||
    -                event.target.type === "text" || $(event.target).prop('contenteditable') == 'true' )) {
    +                event.target.type === "text") ) {
                    return;
                }
    

    From a packaging point of view it does not seem to be a good approach to remove files provided by the upstream software unless there is a package providing exactly the same files.

  10. Loic Dachary

    A bug report was filed against the debian python-coverage package to record the fact that substituting upstream files with other files that are not identical is a mistake. I suspect the issue reported here is environmental (i.e. it does not come from coverage.py) and does not even originate from incorrect dependencies. The purpose of this bug report simply is to state the problem in an environment where packagers are more likely to pay attention.

  11. Ben Finney

    Thanks again for reporting the issue [0] on Debian's ‘python-coverage’ package, Loic.

    On 14-Dec-2016, Loic Dachary wrote:

    From a packaging point of view it does not seem to be a good approach to remove files provided by the upstream software unless there is a package providing exactly the same files.

    The policy for Debian packages strongly discourages bundled copies of third-party libraries [1]. When there is an issue with a library bundled in, for example, Coverage.py, it is not the Coverage.py maintainers who are most knowledgeable about how to fix that library.

    Instead, those libraries should be packaged separately, so that there is a more direct connection between maintaining the library package and maintaining the library code.

    This is also necessary to make security updates manageable: a library that could be bundled in many packages is thereby instead addressed in one package, where all dependent packages can benefit from bug fixes.

    So, the bundled third-party libraries in Coverage.py are not used for the Debian package. Where feasible those libraries are in separate Debian packages and declared explicitly as dependencies.


    This does imply that Coverage.py, for example, needs to work with bug-fixed later versions of the library when Debian releases those bug fixes. When that breaks dependent software, there is a change needed to ensure compatibility, but that's normal software maintenance.

    In this discussion, we've learned that the ‘jquery-hotkeys’ library appears to have acquired incompatible APIs in different versions. That makes it a pain for dependent software, and should IMO be addressed by choosing libraries that make better API compatibility promises.

    Debian bug#848188 is resolved by removing the references to the ‘jquery-hotkeys’ library (and thereby disabling that functionality in Debian's ‘python-coverage’ packages).

    If the ‘jquery-hotkeys’ library ever gets published in a form that has a reliable API for Coverage.py and others to use, or if some replacement library with better API stability is used in Coverage.py, this can be resolved better.

    When a hypothetical new version of Coverage.py has switched to using an equivalent library that has releases stable enough to rely on, I'd welcome a bug report on the Debian ‘python-coverage’ package to that effect.


    [0] Debian bug#848188 <URL:https://bugs.debian.org/848188>;. [1] Debian Policy §4.13, “Convenience copies of code” <URL:https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles>;.

  12. Log in to comment