form input is not display right in mojave
Reported by
qq605231...@gmail.com,
Jun 6 2018
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.15 Safari/537.36 Steps to reproduce the problem: 1. open chromium bug report page, you will find in step 2, the select box is not displaying What is the expected behavior? What went wrong? input element not render properly Did this work before? No Chrome version: 68.0.3440.15 Channel: dev OS Version: OS X 10.14.0 Flash Version:
,
Jun 6 2018
in additional the checkbox in devtool is not rendering too. eg: network -> preserve log
,
Jun 6 2018
This sounds like issue 847518 (restricted) but that should be fixed in 68.0.3440.12 and higher. Can you try on Chrome Canary and attach a screen shot?
,
Jun 6 2018
Hi Rsesek, it's not fixed, i tried chrome canary 69.0.3451.0, and it shows same as 68.0.3440.15 dev version. I attached screenshot here. FYI, issue 849689 is tagged label Proj-Mac1014, maybe we need decide which label to use for future issues related to mojave/10.14
,
Jun 6 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 6 2018
,
Jun 6 2018
(also, please refrain from cross-posting like on issue 850098)
,
Jun 7 2018
Does not reproduce with --no-sandbox, so need to figure out what we are missing. Unfortunately --enable-sandbox-logging does not appear to be working.
,
Jun 8 2018
,
Jun 14 2018
Still happening on Mojave in Chrome 67.0.3396.87, Canary 69.0.3457.0, and Chromium 68.0.3415.0. Not showing up in Safari or Firefox.
,
Jun 16 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e7652b9e1dbc2a95964864161283f4b8665154f3 commit e7652b9e1dbc2a95964864161283f4b8665154f3 Author: Robert Sesek <rsesek@chromium.org> Date: Sat Jun 16 05:25:09 2018 [Mac] Fix form control rendering on 10.14 Mojave. The renderers need to talk to the CVMS server (OpenCL compiler), which then outputs codesigned blobs that can be loaded in to the process. This is required for drawing the form controls. In addition, another Metal bundle location (in /Library) is permitted. Bug: 850021 , 847518 Change-Id: I67106972baf5fc55fccd8f7deff3f47cbea076b5 Reviewed-on: https://chromium-review.googlesource.com/1103127 Reviewed-by: Greg Kerr <kerrnel@chromium.org> Commit-Queue: Robert Sesek <rsesek@chromium.org> Cr-Commit-Position: refs/heads/master@{#567877} [modify] https://crrev.com/e7652b9e1dbc2a95964864161283f4b8665154f3/services/service_manager/sandbox/mac/renderer_v2.sb
,
Jun 17 2018
Working in Canary 69.0.3463.0 now.
,
Jun 18 2018
I am still seeing the issue in Canary 69.0.3463.0
,
Jun 18 2018
i can confirm it's fixed on canary 69.0.3463.0
,
Jun 18 2018
macos 10.14 Beta (18A293u) Chrome Version 69.0.3463.0 (Official Build) canary (64-bit) not working still has that bug
,
Jun 18 2018
can you share the non-working URL so I can test too?
,
Jun 18 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/85afa9864df6d1a5318d6e4f22a3855bdbdb0913 commit 85afa9864df6d1a5318d6e4f22a3855bdbdb0913 Author: Giovanni Ortuño Urquidi <ortuno@chromium.org> Date: Mon Jun 18 08:08:33 2018 Revert "[Mac] Fix form control rendering on 10.14 Mojave." This reverts commit e7652b9e1dbc2a95964864161283f4b8665154f3. Reason for revert: SandboxV2Test.SandboxProfileTest is failing on mac The test has been failing since this CL landed. There doesn't seem to be any other culprit. A lot of tests have been failing on mac for a while, so apologies in advance if this revert is incorrect. https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Mac10.10%20Tests/33158 [ RUN ] SandboxV2Test.SandboxProfileTest [29390:779:0615/235812.468905:11042865975282:WARNING:test_suite.cc(240)] Test launcher output path /var/folders/9x/6c6sv3cj4j53wzpzthbp4ksm0000gm/T/.org.chromium.Chromium.u2ydbY/test_results.xml exists. Not adding test launcher result printer. [29390:779:0615/235812.562300:11042959366455:FATAL:sandbox_mac_v2_unittest.mm(113)] Check failed: result. line 123: unbound variable: prefix 0 content_unittests 0x000000010a96c29c base::debug::StackTrace::StackTrace(unsigned long) + 28 1 content_unittests 0x000000010a8f3171 logging::LogMessage::~LogMessage() + 225 2 content_unittests 0x0000000108751c4b content::SandboxProfileProcess() + 3499 3 content_unittests 0x000000010a128248 base::TestSuite::Run() + 104 4 content_unittests 0x000000010a13ba1c base::(anonymous namespace)::LaunchUnitTestsInternal(base::OnceCallback<int ()>, unsigned long, int, bool, base::OnceCallback<void ()>) + 284 5 content_unittests 0x000000010a13b8d0 base::LaunchUnitTests(int, char**, base::OnceCallback<int ()>) + 160 6 content_unittests 0x000000010874fbf6 main + 198 7 libdyld.dylib 0x00007fff993895c9 start + 1 ../../content/renderer/sandbox_mac_v2_unittest.mm:182: Failure Expected equality of these values: exit_code Which is: 1 0 Stack trace: 0 content_unittests 0x000000010e5750cb testing::internal::UnitTestImpl::CurrentOsStackTraceExceptTop(int) + 91 1 content_unittests 0x000000010e574a89 testing::internal::AssertHelper::operator=(testing::Message const&) const + 89 2 content_unittests 0x000000010df21a94 content::SandboxV2Test_SandboxProfileTest_Test::TestBody() + 804 [ FAILED ] SandboxV2Test.SandboxProfileTest (273 ms) Original change's description: > [Mac] Fix form control rendering on 10.14 Mojave. > > The renderers need to talk to the CVMS server (OpenCL compiler), which > then outputs codesigned blobs that can be loaded in to the process. This > is required for drawing the form controls. > > In addition, another Metal bundle location (in /Library) is permitted. > > Bug: 850021 , 847518 > Change-Id: I67106972baf5fc55fccd8f7deff3f47cbea076b5 > Reviewed-on: https://chromium-review.googlesource.com/1103127 > Reviewed-by: Greg Kerr <kerrnel@chromium.org> > Commit-Queue: Robert Sesek <rsesek@chromium.org> > Cr-Commit-Position: refs/heads/master@{#567877} TBR=kerrnel@chromium.org,rsesek@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 850021 , 847518 Change-Id: Ife268e2d49abc98ad3708545223667e0fb12190c Reviewed-on: https://chromium-review.googlesource.com/1104037 Reviewed-by: Giovanni Ortuño Urquidi <ortuno@chromium.org> Commit-Queue: Giovanni Ortuño Urquidi <ortuno@chromium.org> Cr-Commit-Position: refs/heads/master@{#567946} [modify] https://crrev.com/85afa9864df6d1a5318d6e4f22a3855bdbdb0913/services/service_manager/sandbox/mac/renderer_v2.sb
,
Jun 18 2018
please check the attachment https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_checkbox
,
Jun 18 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1d697363b3e0aa5bf682fcec15ee57ff615068bd commit 1d697363b3e0aa5bf682fcec15ee57ff615068bd Author: Robert Sesek <rsesek@chromium.org> Date: Mon Jun 18 16:49:16 2018 Reland "[Mac] Fix form control rendering on 10.14 Mojave." This is a reland of e7652b9e1dbc2a95964864161283f4b8665154f3 Original change's description: > [Mac] Fix form control rendering on 10.14 Mojave. > > The renderers need to talk to the CVMS server (OpenCL compiler), which > then outputs codesigned blobs that can be loaded in to the process. This > is required for drawing the form controls. > > In addition, another Metal bundle location (in /Library) is permitted. > > Bug: 850021 , 847518 > Change-Id: I67106972baf5fc55fccd8f7deff3f47cbea076b5 > Reviewed-on: https://chromium-review.googlesource.com/1103127 > Reviewed-by: Greg Kerr <kerrnel@chromium.org> > Commit-Queue: Robert Sesek <rsesek@chromium.org> > Cr-Commit-Position: refs/heads/master@{#567877} Bug: 850021 , 847518 Change-Id: Ieb345079a0923d62b034425baacdfc604153c22b Reviewed-on: https://chromium-review.googlesource.com/1104517 Reviewed-by: Greg Kerr <kerrnel@chromium.org> Commit-Queue: Robert Sesek <rsesek@chromium.org> Cr-Commit-Position: refs/heads/master@{#568038} [modify] https://crrev.com/1d697363b3e0aa5bf682fcec15ee57ff615068bd/services/service_manager/sandbox/mac/renderer_v2.sb
,
Jun 19 2018
As a workaround, I have made this tiny Chrome extension (https://github.com/hansemannn/chrome-mojave-checkbox-extension) that uses a 1.000001 zoom-factor to display input elements again. Definitely no long-term solution, but may be helpful until fixed.
,
Jun 19 2018
This is working for me in 69.0.3464.0 on 10.14 18A293u. If it is not working for you, please post more details about your configuration, the test URL you're using, a screen shot, and whether or not the same page works in Safari.
,
Jun 19 2018
Fixed for me in 69.0.3466.0 on 10.14 (18A239u)
,
Jun 19 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fbc5fc44d00a15248a04e107ecb85959503e4044 commit fbc5fc44d00a15248a04e107ecb85959503e4044 Author: Robert Sesek <rsesek@chromium.org> Date: Tue Jun 19 16:04:44 2018 [BRANCH ONLY] Fix seatbelt profile issue on macOS 10.10. This is a rollup of revert 85afa9864df6d1a5318d6e4f22a3855bdbdb0913 and reland 1d697363b3e0aa5bf682fcec15ee57ff615068bd. The original CL fixes form control rendering on macOS 10.14 but used seatbelt syntax not available on 10.10. That resulted in all 10.10 users getting immediate Aw Snaps. This CL is the delta between the original CL and the reland. Bug: 854055, 850021 , 847518 Change-Id: I8230db0f34196b88557762a51f278bd2079961ce Reviewed-on: https://chromium-review.googlesource.com/1106298 Reviewed-by: Robert Sesek <rsesek@chromium.org> Cr-Commit-Position: refs/branch-heads/3464@{#3} Cr-Branched-From: 6017edbbf558d8d85363f3020d788d58039f930d-refs/heads/master@{#567918} [modify] https://crrev.com/fbc5fc44d00a15248a04e107ecb85959503e4044/services/service_manager/sandbox/mac/renderer_v2.sb
,
Jun 22 2018
Hi still not working on 10.14 Beta 2 (18A314h) on my Macbook Air (2013). To reproduce the bug, I was on this page : https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_checked With a 100% zoom, I can't see checkboxes. Same page works fine on Safari. Thx for your work
,
Jun 22 2018
Is it consistently reproducible for you? If you open multiple tabs to that page, do they all fail to paint?
,
Jun 23 2018
Consistently reproducible for me on 69.0.3469.2, 10.14 (18A314h). Using https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_checked with single or multiple tabs. Works as expected on Safari.
,
Jun 25 2018
@Rsesek : yes, with multiple tabs of that page, they all fail to paint. Still same issue with the latest build (69.0.3472.0)
,
Jun 25 2018
,
Jun 26 2018
Hi, it's fixed for me in version 69.0.3473.0 :)
,
Jun 27 2018
It was fixed in a couple versions for me and now it's broken again in Canary 69.0.3473.0
,
Jun 27 2018
Ah, I think the inconsistent behavior is related to the new sandbox technology we're rolling out. The fix is only in the new sandbox since we expect it to be fully deployed soon (canary is being held in an A/B experiment for various reasons). If you go to chrome://flags find "Mac V2 Sandbox" and Enable it, this should be consistently fixed.
,
Jun 28 2018
I tried changing that flag in the latest Dev release and it fixed it for me.
,
Jul 2
Issue 857457 has been merged into this issue.
,
Jul 3
now broken again on 68.0.3440.42 and 69.0.3480.0 with macos 10.14 Beta (18A326g) no change with "Mac V2 Sandbox" Enable
,
Jul 4
Hi! Still reproducible in OSX Mojave 3rd beta (available last night) 18A32g. Latest Chrome stable and Canary are not rendering input type checkbox and file. Latest Firefox is rendering them. Latest Safari is rendering them. Versions: Google Chrome: Version 68.0.3440.42 (Official Build) beta (64-bit) Google Chrome Canary: Version 69.0.3481.0 (Official Build) canary (64-bit) Firefox: 61.0 (64-bit) Safari: Version 12.0 (14606.1.22.2) You can see more screenshots at https://twitter.com/montogeek/status/1014467767880298497
,
Jul 4
Just tried activating Mac V2 Sandbox flag. It doesn't work neither in Beta or Canary.
,
Jul 4
With the update to 10.14 (18A326g) this reverted from being fixed in Canary 69.0.3481.0 with the Sandbox flag enabled or set to default. Multiple tabs exhibit the same problem. Does not occur in Safari.
,
Jul 5
Still broken with Canary 69.0.3482.0 and the beta 3 build 18A326g ("Mac V2 Sandbox" enabled or disabled).
,
Jul 9
Issue 861615 has been merged into this issue.
,
Jul 9
Issue 861693 has been merged into this issue.
,
Jul 9
,
Jul 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/baaa9de4ec2fbac63380628483928fca65eba70c commit baaa9de4ec2fbac63380628483928fca65eba70c Author: Robert Sesek <rsesek@chromium.org> Date: Tue Jul 10 18:56:24 2018 [Mac] Allow more CVMS file object reads in the 10.14 sandbox. Beta 3 18A326g added new locations for CVMS files. Bug: 850021 Test: Form controls render correctly in web content. Change-Id: I00f93a847d1dbb086edea318526aab74bddb54bc Reviewed-on: https://chromium-review.googlesource.com/1130163 Reviewed-by: Greg Kerr <kerrnel@chromium.org> Commit-Queue: Robert Sesek <rsesek@chromium.org> Cr-Commit-Position: refs/heads/master@{#573837} [modify] https://crrev.com/baaa9de4ec2fbac63380628483928fca65eba70c/services/service_manager/sandbox/mac/renderer_v2.sb
,
Jul 10
Hardly scientific, but I tried setting in about:flags "Use Blink's zoom for device scale factor." On a Macbook Pro 2016 15" Having done so, radio boxes now appear at 100% zoom. I have no idea what I may have broken but hopefully this may help some people workaround, or identify the actual issue
,
Jul 10
This issue got press last week: https://lifehacker.com/how-to-fix-chromes-checkboxes-and-buttons-in-macos-moja-1827398550
,
Jul 11
The extension in lifehacker's article is not working for me. The flag "Use Blink's zoom for device scale factor." is working well, but the rendering is not the same with factor 100% and 100.1% (see attached screenshots). All tests were done with version 69.0.3488.0 (the latest)
,
Jul 12
Yes my understanding is that the flag forces chrome to use a less favourable scaling mechanism which is now superceeded .. but I tried it as an alternative scaling approach to see if it at least offered a short term workaround until either MacOS or chrome is fixed to address the issue
,
Jul 18
This problem persists with yesterday's MacOS beta 10.14 Beta (18A336e) & chrome beta 68.0.3440.59 (Official Build) beta (64-bit) The flag I previously mentioned does cause other issues with layouts - for example values in selectable lists appear bottom right not in-situ
,
Jul 18
This seems to be solved with 69.0.3493.3 and macOS 10.14 Beta 4.
,
Jul 19
Not fixed for me with 69.0.3496.0 and macOS 10.14 Beta 4 (18A336e) I have to activate "Use Blink's zoom for device scale factor."
,
Jul 22
not fixed for me with 68.0.3440.68 (beta) and 18A336e However it seems fixed in canary 70.0.3499.0 for me
,
Jul 22
Looks good to me on Dev channel (69.0.3493.3) and macOS 10.14 Beta 4 (18A336e). I do not have Blink's zoom for device scale factor enabled and it still looks good
,
Jul 23
It seems to be corrected since 2-3 builds but the rendering is not the same with a zoom 100% and 90%/110%
,
Jul 23
#58: Yup, that is a known behavior in WebKit-based browsers - Safari has it as well.
,
Jul 23
,
Jul 26
Issue 867936 has been merged into this issue.
,
Jul 30
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by qq605231...@gmail.com
, Jun 6 2018