[Bug] Code viewer search widget misbehaviors

[MasterInQuestion]

    (uBO 1.63.2)

    |1| The "maximize" button introduced in:
    https://github.com/gorhill/uBlock/commit/664dd9570064576b2cfeeb00dea6de1ae7b040fc
    ; simply broke the interface.
    (whole widget outright disappeared with no way to turn back)
    [ ^ Fix: https://github.com/gorhill/uBlock/commit/97e740bd2c200b054358593c45186a7b754ca97f ]

    |2| The result count display is formatted in a manner unfit for large counts. (that mostly designed for file size)
    Use simple number grouping should suffice. (i.e. 10,000 alike)
    [ ^ Is this bug essentially CodeMirror's problem? (I doubt so) ]

    @gwarser

[ghost]

How to reproduce? Some large file?

[MasterInQuestion]

    Try search "0":
    https://github.com/MasterInQuestion/attach/raw/main/microsoft/vscode/240890/1m-lines.txt
    [ ^ Search for /\d+/ instead seems more demonstrative. ]

    Refer also:
    https://old.reddit.com/r/kiwibrowser/comments/1j6p5jf?sort=old#mkbeudf
    (uBO's Code viewer shall be loadable from direct extension URI)

[ghost]

    Editor is failing:

[MasterInQuestion]

    It's "Code viewer" ("/code-viewer.html"), not "My filters".

    The failing would be CodeMirror cause.
    (inability handling too large file?)

    Meanwhile try the alternative file?
    https://kirill.korins.ky/pub/ffplay-framerate-60.log
    (that reproduced the demo image)

[MasterInQuestion]

    There are also several other issues about Code viewer:
    |1| [
    Lacking support for non-UTF-8.
    E.g. https://app.alipay.com/
    https://product.dangdang.com/25168338.html
    ; resulted in garbled display.

    I did note some past related:
    https://github.com/uBlockOrigin/uBlock-issues/issues/2656#issuecomment-2365177384
    https://github.com/gorhill/uBlock/issues/3405#event-7849932834
    .
    But Code viewer seems to only require decoding.
    (thus "TextEncoder" shall work?)

    Does the overall missing support for non-UTF-8:
    Also indicate that sites may exploit it, as ad-block circumvention..? ]

    |2| [
    Request from Code viewer seems not using the ideal HTTP Accept. (currently seems unconditional `*/*`?)
    Fundamentally would be a browser issue:
    Request of different sources maybe differently assigned Accept.
    .
    https://bugzilla.mozilla.org/show_bug.cgi?id=1879929
    https://searchfox.org/mozilla-central/search?q=http.accept
    https://github.com/mozilla/gecko-dev/blob/5bea6ede57be43d450ecc24af7a535288c9a9f7d/netwerk/protocol/http/nsHttpHandler.cpp#L666-L683

    But for the Code viewer's context:
    It's acceptable to simply copy the Accept that invoked the "/code-viewer.html" document.
    (as the explicit Accept, for the Fetch/XHR to load the request target)
    That should align with the user configured HTTP Accept of the browser generally. ]

    |3| Unconditional auto-focus to content upon finished loading maybe obtrusive:
    User might be at focus in the search widget, typing the expected content to filter meanwhile.
    The abrupt focus change tends to be unpleasant experience.
    (typing unintentionally goes into the response content)