Develop Reference

Why doesn't capture="user" change my phone's camera to front facing?

I tried the following attribute capture to set the input element to try to select the front facing camera. user is front facing, and environment is back facing.
However, while experimenting with Chrome (latest) on mobile (Pixel 1, latest OS), the back camera is still selected.
I used an example snippet:
<form action="server.cgi" method="post" enctype="multipart/form-data">
<input type="file" name="image" accept="image/*" capture="user">
<input type="submit" value="Upload">
</form>
(from https://w3c.github.io/html-media-capture/#the-capture-attribute)
I am able to change accept to require video on my phone, so that and other attributes work, but not the capture attribute.
EDIT: Am using the latest Android Chrome browser. The following page implies that iOS and older versions of Android Chrome cannot use capture altogether, but otherwise can use capture. https://caniuse.com/#search=html-media-capture

I cloned the chromium repository today (2019-07-21). I then used ripgrep to get a list of files that do not contain capture. After passing that list to rm, I removed any directories that were either empty or clearly irrelevant (such as telemetry). Going through the remaining ~50 files was a relatively trivial task.
Hopefully the Chrome team will get around to implementing this in the future, but there is currently no indication that this behavior is supported in official documentation, official blog posts, or the code itself.
I know it's not the answer you'd like to hear, but those are the facts as I've found them.

Would it be Chrome specifically that hinders the code from working properly? I suggest using a different browser such as Firefox in order to test this theory. If it does succeed on Firefox, then the simple answer is: Chrome has yet to implement it yet.

Here are some tests, I included user agent:
Didn't worked with :
Android Chrome: Mozilla/5.0 (Linux; Android 6.0; Ilium X510) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.143 Mobile Safari/537.36
Android Firefox: Mozilla/5.0 (Android 6.0; Mobile; rv:68.0) Gecko/68.0 Firefox/68.0
Worked with :
IPhone Chrome: Mozilla/5.0 (iPhone; CPU iPhone OS 12_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/75.0.3770.103 Mobile/15E148 Safari/605.1
IPhone Safari: Mozilla/5.0 (iPhone; CPU iPhone OS 12_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Mobile/15E148 Safari/604.1
In Summary:
All tested iPhone navigators displayed the front camera view when capture is user, and back camera view if it is environment.
Both tested Android navigators displayed always the back camera view.
So regardless the information in the accepted answer, it doesn't seem to be a browser issue. It would be helpful if it works correctly with an Android device and a specific browser.
I hope other people can share tests on their Android devices, in particular on working ones, displaying front camera view while testing the capture="user" attribute-value.

Inconsistent background-size shorthand behavior between Chromium 51 and Chromium 51 WebView

I have encountered strange behavior in our application, which is a Phonegap wrapped WebView running on Android. I'm not sure if I'm looking at a bug or there could be other causes, hence this question.
Roughly since 2013 for Chromium, the background CSS property can also contain the shorthand definition of background-size, separated by /.
Ex: background: green url(../img/hk.svg) center center / 100% auto
This syntax works obviously well in the Chrome browser for Android, tested on UA Chrome/51.0.2704.81. Since KitKat, the Chromium core present in the system is also used for WebView instead of the stock browser, so our Phonegap application uses the exact same rendering core (Chrome/51.0.2704.81) as the Chrome application.
However, the background-size shorthand does not work in the WebView variant. In dev tools, the syntax is shown as correct, but behaves as if the background-size definition in the background string didn't exist. If the background-size is explicitly set afterwards, the issue is resolved.
Below, I am providing a small contained .apk that you can use to test this behavior by debugging through device inspection in Chrome.
Full UA Chrome string: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5 Build/MOB30D) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.81 Mobile Safari/537.36
Full UA Chrome WV string: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5 Build/MOB30D; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36
Test case for Chrome browser - codepen
Test case APK for Android - minimal Phonegap Hello World wrapper, no perms requested
The APK uses the following relevant HTML/CSS:
<div class="block"></div>
<div class="block extended"></div>
.block { background: green url(../img/hk.svg) center center / 100% auto; }
.extended { background-size: 100% auto; }
As you will observe, only the div with .extended class will render correctly, while both should instead.
Thank you!

I exploded the APK file you posted and copied your source code to my newly created cordova project. I built my project and tested in device running on Android Marshmallow. It works fine. Please find the screenshot of the result too.
Have also added the sample project in my github page. Request you to have a look at it and generate APK from the same as this could be an issue with your project setup. I m using cordova version 6.2.0 and Cordova Android version 5.1.1
Also i came across on other link which states you gotta specify position (0%) before using background-size shorthand. You may try out that option once in your setup. Hope it helps

As reported here, background-size shorthand for android webview does not work below version 4.4 (api level 19).
But I think there are also few more problems with kitkat (look at this question:background-sizecover-not-working-in-android-native-browser).

Changing Android's WebView display from Desktop Mode back to Mobile Mode

I'm developing a browser which is supposed to allow toggling between mobile and desktop modes.
When changing to desktop mode via the following code:
mWebView.getSettings().setUserAgentString("\"Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31");
mWebView.getSettings().setBuiltInZoomControls(true);
mWebView.reload();
It's all good. However, when trying to change back to mobile mode via the following code:
mWebView.getSettings().setUserAgentString("Mozilla/5.0 (Linux; Android 4.1.1; HTC One X Build/JRO03C) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.58 Mobile Safari/537.31");
mWebView.getSettings().setBuiltInZoomControls(false);
mWebView.reload();
The page is reloaded, but it's still displayed in desktop mode.
It's worth noting that when testing this on YouTube, after triggering the 2nd code segment I AM able to return to mobile mode if I manually insert "https://m.youtube.com" into the address bar (something which is not possible when in desktop mode and before triggering the 2nd code segment). So it seems that resetting the UserAgent, while not providing the desired result, is not worthless after all.
So, assuming that changing the domain prefix from "www" to "m" programmatically is a somewhat hacky solution, how can mobile mode be automatically restored?
Edit:
As for clearing WebView's cookies - it solves the problem, but it seems that while it is trivial to clear ALL cookies, that is not the case when trying to clear only those cookies which belong to a specific domain. Clearing everything is not an option in my case.

Android, webview user agent vs browser user agent

I'm building my website and I want to know whether the user is using Android's browser or an app with a webview.
is it possible ??

As per Chrome dev docs: "If you’re attempting to differentiate between the WebView and Chrome for Android, you should look for the presence of the Version/X.X string in the WebView user-agent string."

FROM: http://googlewebmastercentral.blogspot.com/2011/03/mo-better-to-also-detect-mobile-user.html
With a User-Agent like this:
Mozilla/5.0 (Linux; U; Android 3.0; en-us; Xoom Build/HRI39) AppleWebKit/534.13 (KHTML, like Gecko) Version/4.0 Safari/534.13
since there is no “mobile” string, serve this user the desktop version (or a version customized for Android large-screen touch devices). The User-Agent tells us they’re coming from a large-screen device, the XOOM tablet.
On the other hand, this User-Agent:
Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
contains “mobile” and “android,” so serve the web surfer on this Nexus One the mobile experience!
FROM https://stackoverflow.com/a/7327201
it looks like the User-Agent is the same in webview as in the default mobile browser

FYI: This can't be done with user agents, however it can be detected. Android's web views send an addition header "X-Requested-With". The value of this header will be the application's name space that is running the webview.
For Example Dolphin browser sends: "mobi.mgeek.TunnyBrowser"
My test app sent: "com.jamestymann.identifyawebview"
The standard browser actually does not send this header at all, so it is pretty easy to detect these.
I have two caveats though:
"X-Requested-With" is a standard header and could potentially be sent from full blown webpages/browsers from desktops. (For example this is used to detect ajax calls with these values "X-Requested-With XMLHttpRequest")
Most google play store browsers use webviews to display webpages. Even though these are full blown browsers, they will still send this header. So if your intent is to disable this feature you may want to be careful as you may be disabling peoples default browsers.

For more current information, look here https://developer.chrome.com/multidevice/user-agent The lolipop and newer devices include wv) in the UserAgent.

You can used below code for checked android webview or browser.
public static bool is_mobile_and_webview()
{
return System.Web.HttpContext.Current.Request.Browser.IsMobileDevice && System.Web.HttpContext.Current.Request.UserAgent.Contains("; wv");
}

yes and you can optimize your website by adding these meta tags
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />
<meta name="HandheldFriendly" content="True" />
you can find more information here http://learnthemobileweb.com/2009/07/mobile-meta-tags/

I use this serverside, to access info about client' browser (agent) in PHP
...
$_SERVER['HTTP_USER_AGENT']; // Different browsers ...
...
this boilerplate can be interpreted - hence you will know the agent ...
on client side - navigator.userAgent

Web App Compatibility on Mobiles

I am new to Mobile Development . I am developing a Web Page for Android Mobiles..I am testing the Page using User Agent .
Mozilla/5.0 (Linux; U; Android 2.2.1; en-ca; LG-P505R Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
Is this works only in the model which is specified or It will work well in all the Android Mobiles ?
And I want to know ,whether the web page alignments will be changes when the Mobile size changes ?
Thanks in advance .

Govind,
I am thinking there are probably several answers to your question. From my perspective, as a .NET developer, I would go with the method described on this CodeProject page to detect the "mobile-ness" of the client's browser. If you're strictly looking in the User Agent though, look how the word "Android" shows up in there. Just make sure your comparison code contains the word "android" without any other stuff and ignoring case and you should be fine.
As far as the size changes, your mobile device will try to do its best to show you the page you want to view. This could mean it just "zooms out" so everything looks tiny, or maybe it only shows you a small chunk of the page in its regular size. You should look into responsive design techniques. All the documentation I've read on the subject says it is more beneficial to load a separate page, or at least a separate set of CSS, instead of your normal site and/or CSS for mobile browsers. Then you can optimize the scripts and CSS and even HTML code shown in the page for these devices.
Good luck,
Matt