Android Chrome: Known Issue

[Pøĸē]

I don't even have the update available

[J. Gatsby]

Pøĸē
Me neither

[Mer-ith-ew]

There's no update for me in the app store!!!!!!! WHAT!?

[Zero Dade Cool]

404 update not found here either. WHO has this update? Not me.

[flyonthewall]

I don't even see that update.

[xea989]

Not seeing the ALLEGED update in New Zealand.

I did see all the reports about this on ProBoards Support. IDK where those people live.

[Hulk]

I don't have this update in the Play Store. I'm good.

[Tampaboy19N]

Weird how there are so many reports on Support and none of us can access the update lol.

[accuber]

^PB wants to keep us online

[Jaxon]

No updates for me.

[bigballofyarn]

Nov 16, 2024 10:32:48 GMT -5 @horace said:

Background<svg viewBox="0 0 16 16" height="24" version="1.1" width="24" 

The <select> element does not provide enough customization for web developers, which leads them to implement their own. These implementations can lead to reduced performance, reliability, and accessibility compared to the native form control elements. More on that is in Custom Control UI.

The 2020 MDN browser compatibility report had feedback that form controls are neither interoperable nor customizable. Customizable <select> will be fully interoperable and customizable.

Opting in to the new behavior<svg viewBox="0 0 16 16" height="24" version="1.1" width="24" 

The <select> element will continue to behave as it currently does unless it has the appearance:base-select CSS property. Based on standardization discussions, appearance:base-select must also be applied to the select::picker(select) pseudo-element in order to opt in the picker popup element. Previously proposed opt-ins included a new tag name, an additional HTML attribute, and the presence of a child <button> or <datalist>.

Here is a basic <select> element with the appropriate CSS to opt in to customizable <select>

Testing out the customizable select element<swidth="24" xlmns="http://www.w3.org/2000/svg"><path d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2

Customizable <select> is currently implemented behind a flag in Chromium. To use it, enable the Experimental Web Platform features flag in about:flags. Using chrome canary is recommended to get the latest state of the API.

If you encounter bugs or limitations with the design of the control, please send your feedback by creating issues on the open-ui GitHub repository. Here is a list of open select bugs in open-ui.

Read More...

There may apparently be a bug where Chrome Mobile on Android automatically opts in for page author (Mobile Issue)

Nov 16, 2024 12:05:29 GMT -5 @horace said:

Nov 16, 2024 11:44:50 GMT -5 @bigballofyarn said:

@horace ,

Do you mind if I quote your message here and post it on my forum in the thread regarding this issue?

Sure! But be aware that the last part is pure conjecture on my part since I have not seen any bug reports regarding it. It could just as easily be years of reliance on lazy markup in the mobile offering now coming to roost. I do not have a v131 to play with yet.

[Rick]

I don't have the option to update.
Tapa user anyway.

[Mr. Tuxedo]

Was looking forward to seeing the bug but there's no update for me.

Sticking with Tapatalk.

[flamewolf]

Maybe Pøĸē can explain that code stuff to us

[Pøĸē]

If I am reading correctly it sounds like Chrome is making changes to how certain page elements work. Those changes are behind a configuration which is supposed to be OFF by default but on the mobile Chrome update it is ON (conjecture from horace). If this is the case, then it seems like the changes are probably not done and have other unintended consequences which break page functionality.