Skip to content
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

[GENERIC viewer] Re-factor the fileInput initialization #14767

Merged
merged 2 commits into from
Apr 10, 2022

Conversation

Snuffleupagus
Copy link
Collaborator

This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.

The fileInput-element is used to support the "Open file"-button in the GENERIC viewer, however this is very old code.
Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the fileInput-element currently has a number of unnecessary CSS rules, since the element is purposely never made visibly.

Note that with these changes, the fileInput-element will now always have display: none; set. This shouldn't matter, since we can still trigger the click-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.

*This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.*

The `fileInput`-element is used to support the "Open file"-button in the `GENERIC` viewer, however this is very old code.
Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the `fileInput`-element currently has a number of unnecessary CSS rules, since the element is *purposely* never made visibly.

Note that with these changes, the `fileInput`-element will now *always* have `display: none;` set. This shouldn't matter, since we can still trigger the `click`-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.
@Snuffleupagus
Copy link
Collaborator Author

/botio-linux preview

@pdfjsbot
Copy link

pdfjsbot commented Apr 9, 2022

From: Bot.io (Linux m4)


Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.241.84.105:8877/3829dfb888ca992/output.txt

@pdfjsbot
Copy link

pdfjsbot commented Apr 9, 2022

From: Bot.io (Linux m4)


Success

Full output at http://54.241.84.105:8877/3829dfb888ca992/output.txt

Total script time: 2.60 mins

Published

…Input`

According to the MDN compatibility data, see below, all of these features have been supported for years and years in all browsers. Looking closely at the data, the most likely reason for adding these checks in the first place was for IE 9 compatibility (since we originally "supported" that browser).

 - https://developer.mozilla.org/en-US/docs/Web/API/File#browser_compatibility
 - https://developer.mozilla.org/en-US/docs/Web/API/FileReader#browser_compatibility
 - https://developer.mozilla.org/en-US/docs/Web/API/FileList#browser_compatibility
 - https://developer.mozilla.org/en-US/docs/Web/API/Blob#browser_compatibility
@timvandermeij timvandermeij merged commit 143ba30 into mozilla:master Apr 10, 2022
@timvandermeij
Copy link
Contributor

Thank you for simplifying this!

@Snuffleupagus Snuffleupagus deleted the fileInput-refactor branch April 10, 2022 13:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants