Also, avoid calling SendFindImageText() on unsupported platforms, so that
test_image_recognition_unsupported.html will pass.
Differential Revision: https://phabricator.services.mozilla.com/D191678
Firefox versions >= 116 only support macOS >= 10.15. Mojave is macOS 10.14. Catalina is macOS 10.15.
Also stop including unused "nsCocoaFeatures.h" in files with no macOS version checks.
Differential Revision: https://phabricator.services.mozilla.com/D185505
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
This code path gets executed by existing tests, and I don't believe
there is a way to execute this behavior using our CI, since it's a macOS
version check.
Differential Revision: https://phabricator.services.mozilla.com/D154172
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
We could expose the text recognition values to JS if need be, but
there's no reason to do that for now. We expose them via the UA
widget DOM for now.
We can trivially do that if we want to build the Shadow DOM in JS
or what not. I decided to still return a promise so that we can
expose errors though.
Differential Revision: https://phabricator.services.mozilla.com/D141113
This is all still unused, but we'll add an JS API to HTMLImageElement
for testing in a bit.
The reason for not having the JS-exposed interface is that dealing with
all the relevant edge cases is pretty hard from JS (think of e.g., the
image source changing mid-recognition, and so on).
The frontend will probably want an "is image recognition available"
boolean, but that doesn't need to be on its own XPCOM component, IMO.
If we need a JS API for unit-testing or something we can always add it
later.
Depends on D141111
Differential Revision: https://phabricator.services.mozilla.com/D141112
Andrew McCreight