I've seen similar questions asked regarding Flutter and other applications, but to give some context, Google's Gboard just changed the way GIFs and emojis insert into the application, but it's unclear how to support it now.
The error above appears when using Gboard to insert an image into an HTML input. I assume there's some way to accept this, but there does not appear to be any documentation on this apart from the obscure change notes on Gboard that say they changed the way they do it.
This was probably fixed in the newest update by Gboard. You can install an APK of an older version of Gboard here and the easiest way to downgrade Gboard for iOS is using a tweak called AppStore ++ but that only works if you are jailbroken.
Otherwise, just try other keyboards such as SwiftKey or Giphy to insert the image into your HTML input.
Related
tldr; Can one get the browser version from the front end without using navigator strings or Client Hints?
So with Google's announcement about freezing the navigator.userAgent string, I've been tasked with going through a bunch of javascript libraries at work in an effort to replace browser sniffing (aka userAgent). I know, I know, we shouldn't use userAgent in the first place because it's a sack of confusion and lies, but I'm inheriting this code and not creating it. Luckily, a bunch of the use cases were dated (IE8-10, PhantomJS, Windows Phone) and I could remove them completely. Others I could figure out which features/intentions the original authors were using and I could swap their conditions for feature detection.
But some of the public facing logic is using navigator.userAgent to figure out the browser version and this has been more challenging to replace because everything I find on the interwebs related to this search points to using one of the navigator properties. I don't know how and why clients care which "version of Firefox a user is on" and I'm awaiting that answer, but in the meantime I'm trying to see if there is a solution out there that can detect browser version on the front end. I'm not restricting the answer to just javascript, if there is a CSS/HTML/JS combination, I'm all for it.
I'm also aware the Google says we should use Client Hints but that requires hitting the server which is out of scope for my task.
Freezing plan via the Google Announcement:
Different parts of the UA string have different compatibility
implications.
Some parts of it, such as the browser version and the OS version, can
be frozen without any backwards compatibility implications. Values
that worked in the past will continue to work in the future.
Other parts, such as the model (for mobile devices) and the OS
platform, can have implications on sites that tailor their UI to the
underlying OS or that target a very specific model in their layout. Such sites will need to migrate to use UA-CH.
If I am reading the second bullet here correctly, then the version parts of the navigator strings will be frozen and unreliable by Early June 2020.
Again, just so it's clear, I know this should be replace by feature detection, but I don't have full control over our clients and users and I'm just seeing if there is a solution out there. I have a feeling lots of folks will end up trying to solve this problem soon enough.
Final Update
For most practical purposes, this question is obsolete as both firefox and chrome have native support for avif through the standard picture html tag with a source marked as type="image/avif". See https://reachlightspeed.com/blog/using-the-new-high-performance-avif-image-format-on-the-web-today/ . Fire fox still likes to hang and often forces a control F5 to bypass caches and requires sending the correct content type from the server. Hopefully will be fixed soon.
Here is the commit where I got avif support working: https://github.com/quackack/quackack-comics/commit/f1a98ed1f40b6a22584d61bc338bd91df3232fa5#diff-e25b0950ce48f4e928f98e0a6fbb694c . Note that it contains many unrelated changes and in fact avif is barely mentioned, only as a content type and a file extension.
Original Question
I am trying to change a website where I host web comics from using jpegs to the newer avif image format. It is much smaller and seems to be the new image format with the most widespread support. Unfortunately, web browsers don't properly support the new format yet. So I was planning to use this package: https://github.com/Kagami/avif.js to allow my comics to be rendered. Some basic tests showed that AVIF would give the same quality as jpeg for less than half the space.
Unfortunately, after more than 5 hours of time spent on this, I am unable to get this to work with my react framework. You can see my website at the time of writing at 'https://github.com/quackack/quackack-comics/tree/cda4c3893d8477192c4ff3aa78d00096b7621ff7'.
I tried using npm install to install avif.js and then added
require("avif.js").register("/avif-sw.js");
to index.js . But I get error
Failed to register/update a ServiceWorker for scope ‘http://localhost:3000/’: Bad Content-Type of ‘text/html’ received for script ‘http://localhost:3000/avif-sw.js’. Must be a JavaScript MIME type
And avif files are still not able to load. I think the requests are getting rerouted to index.html instead of the javascript package. It seems like the appropriate thing to do is something like
import * as avif from 'avif.js';
avif.register('avif.js/avif-sw.js');
But this fails too with the same error, as do many other similar variations.
At this point I am inclined to wait for proper browser support for avif, as I don't get enough traffic to worry about data costs anyway. If this could easily be fixed, then I would love to have the improvements from avif. I just want smaller file sizes and widespread browser support.
Update
Okay, I found that I could get this to work if I changed from the default react bundler (which I believe to be webpack) to Parcel. Then it does work exactly as you expect... until I try to deploy the project.
There is an issue where I cannot load the service worker when i try to deploy my single page webapp to AWS as a single page web app. There it makes a request to my url with avif-sw.js where there is not actually a js file. I believe the issue is closely related to https://github.com/parcel-bundler/parcel/issues/670
So the first key is to use Parcel to build your web app. But Parcel still does something wrong with deployment it seems. I will continue to investigate this in a few days.
Here is the almost working version using parcel: https://github.com/quackack/quackack-comics/tree/parcel
Update 2
My earlier update was incorrect. I only thought it was working because of a cached service worker. My final solution is in the answer below.
It doesn't seem to be a problem now. Simply convert your images to avif with tools like https://avif.io/ and use them as the image source or background source via typical CSS. As Chrome and Firefox now support it (even though users still have to enable it on Firefox), everything goes well. Even works on mobile now! :)
Okay, I finally got it working. Unfortunately, mobile devices don't seem to be able to handle the large file sizes so I had to keep using jpeg anyway. It worked on my laptop though.
Here is the commit that got everything to work: https://github.com/quackack/quackack-comics/commit/75e75307e688f0e515b4bbc9eb22eef290d2c209
What I had to do:
Switch to Parcel.
Copy the contents of the avif.js library into source before building. I used the command:
copyfiles -f node_modules/avif.js/*.js .
Put this specifically into reg.js:
require("avif.js").register("./avif-sw.js");
navigator.serviceWorker.register("./avif-sw.js", undefined);
What the last two steps do is trick parcel into actually keeping a copy of "avif-sw.js" around that can actually be loaded as a service worker. Probably with a bit more tinkering you can get this to work without using parcel at all, just by copying local and then registering. No requires required. But I stopped investigating after I found this solution can't work on mobile.
This was exceptionally hard to debug because service workers are cached by the browser and I had to clear broswer data after every edit. It was also hard to debug because the source files are cached to so I had to delete my projects cache and build frequently too.
You might also want to use npm module "http-server-spa", or similar, to test how your built SPA will act when deployed.
On http://www.dutchsupercross.nl/inschrijven I implemented a captcha at the bottom. But does not seem to work in Internet Explorer.
It also looks like that IE does not like to load HTTPS because i do not see that this file is loaded in the developer tools (Network) When i change it to HTTP it seems to load the javascript but still nothing shows up.
Any ideas are welcome
I checked the website in my Chrome, Mozilla, IE, and Yandex browsers and it worked pretty well. Sometimes the browsers have something about the compatibility.
There is a good documentation in google's recaptcha website. Check the following link and apply the steps under the section "reCAPTCHA isn't displaying properly on Internet Explorer, what do I do?"
The link is: Google reCAPTCHA website
I can't find nearest possible issue,
I don't rely much on dealing browser specific without encourage the user to update their browser.
Since the implication may not only issue like this.
Based on SO question,
we won't and we can't agreed all of that. Which if we decide support IE we should drop IE older than 11 now on.
Which also proper and diligent decision that you take, base on microsoft official documentation
Which i want to highlight is when we decide browser support we also should take care of the browser ecosystem.
That you probably can upgrade the jquery version from 2.1.0 to 2.1.4 which from semantic versioning it's just the patch, that hopefully doesn't break your code.
But futhermore you should include upgrade the minor patch to your working schedule which suit your need and priority.
Frankly i can't find the glance on the change log, so i can't guarantee that this work.
But personally this is better than repetition same debugging process that the result is uncertain.
Action step:
Make sure follow installation recapcha properly.
Which display mode you choose to display the widget ?
Its also have different behaviour.
Recaptcha doc already notice that automatic render is the easiest way. Use this if you don't, but more importantly change this display mode if this
can fix your issue.
It possible jquery bug, but be aware directing it. (Possibilities unreported, not yet fixed, fixed on certain version).
3 Most possible nearest bug for me 1764, 3041 since it will render through iframe
Fixed on certain version :
Work on your code with jQuery changelog
Work on your code, while upgrading it. (have draw back on it's own).
Not yet Fixed.
seek out on jquery issue
seek out on bug
Issue and Bug are differs.
Follow framework or lib specific for re
Unreported and Untracked
It's a bit hard to recaptcha since
I seem to be having a issue using phoneGap with querystrings
I wanted to have a page as:
view.html?matchid=1234
I have also tried:
view.html#1234
Both of these work in the emulator (running 2.3) but neither work when on my phone (ICS 4.0) - It errors as if the page doesn't exists...
I believe it may be a issue with the version of android. Does anyone know of a fix/work around I could possibly do.
Ideally it would be still using the query in some way. If not the other option I thought of was to use localStorage. Save something to it before going to a generic view.html page which then takes the Id out of localStorage....
There is an issue for this in the Android issue tracker.
http://code.google.com/p/android/issues/detail?id=17535
It affects all versions of Honeycomb and ICS.
It has been fixed and marked for Future release, so don't expect it anytime soon.
You can find some workarounds on the issue thread.
I have a Firefox Extension that I would like to populate the About box with the version within install.rdf.
I know that FUEL's extIExtension allows one to see the version for an extension but I did not create the extension using FUEL (and the docs on MDC seem very light on how to transition to it). Is there a way to dynamically check the extension version?
I specifically do not want to hard code or make it generated from my Makefile
#sdwilsh, you're right, my apologizes.
Took me awhile to realize the only FUEL object I have access to is fuelApplication, but it looks like this does it:
let version = Application.extensions.get('extension#id').version;
FUEL is just an API, so it doesn't matter how you implemented your add-on.