New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 39 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
cturner-helpforum-bugs


Sign in to add a comment
link

Issue 850021: form input is not display right in mojave

Reported by qq605231...@gmail.com, Jun 6 2018

Issue description

UserAgent: 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:
 

Comment 1 by qq605231...@gmail.com, Jun 6 2018

to be more specific, <input type="checkbox"> is not rendering right

Comment 2 by qq605231...@gmail.com, Jun 6 2018

in additional the checkbox in devtool is not rendering too.
eg: network -> preserve log

Comment 3 by rsesek@chromium.org, Jun 6 2018

Cc: rsesek@chromium.org
Labels: Needs-Feedback Proj-MacMojave
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?

Comment 4 by qq605231...@gmail.com, 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
屏幕快照 2018-06-06 23.19.34.png
167 KB View Download

Comment 5 by sheriffbot@chromium.org, Jun 6 2018

Project Member
Labels: -Needs-Feedback
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

Comment 6 by rsesek@chromium.org, Jun 6 2018

Cc: -rsesek@chromium.org
Components: -UI Internals>Sandbox Blink>Forms
Labels: ReleaseBlock-Stable M-69 FoundIn-67 FoundIn-68 FoundIn-69
Owner: rsesek@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 7 by rsesek@chromium.org, Jun 6 2018

(also, please refrain from cross-posting like on issue 850098)

Comment 8 Deleted

Comment 9 by rsesek@chromium.org, 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.

Comment 10 by qq605231...@gmail.com, Jun 8 2018

Hi rsesek@, btw just realized input type=file is not working too.
609C60AF-5CF7-4EE1-B14E-3E213B77BBA5.png
47.4 KB View Download

Comment 11 by viswa.karala@chromium.org, Jun 8 2018

Cc: viswa.karala@chromium.org
 Issue 850815  has been merged into this issue.

Comment 12 by e.andthe...@gmail.com, 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.

Comment 13 by bugdroid1@chromium.org, Jun 16 2018

Project Member
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

Comment 14 by e.andthe...@gmail.com, Jun 17 2018

Working in Canary 69.0.3463.0 now.

Comment 15 by m...@m-d.net, Jun 18 2018

I am still seeing the issue in Canary 69.0.3463.0

Comment 16 by qq605231...@gmail.com, Jun 18 2018

i can confirm it's fixed on canary 69.0.3463.0

Comment 17 by kokila....@gmail.com, 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

Comment 18 by qq605231...@gmail.com, Jun 18 2018

can you share the non-working URL so I can test too?

Comment 19 by bugdroid1@chromium.org, Jun 18 2018

Project Member
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

Comment 20 Deleted

Comment 21 by kokila....@gmail.com, Jun 18 2018

please check the attachment
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_checkbox
Screen Shot 2018-06-18 at 8.13.00 PM.png
158 KB View Download

Comment 22 by bugdroid1@chromium.org, Jun 18 2018

Project Member
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

Comment 23 by hansknoe...@gmail.com, 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.

Comment 24 by rsesek@chromium.org, 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.

Comment 25 by c...@thelevelup.com, Jun 19 2018

Fixed for me in 69.0.3466.0 on 10.14 (18A239u)

Comment 26 by bugdroid1@chromium.org, Jun 19 2018

Project Member
Labels: merge-merged-3464
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

Comment 27 by vincent....@gmail.com, 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
Capture d’écran 2018-06-22 à 10.24.42.png
59.1 KB View Download

Comment 28 by rsesek@chromium.org, Jun 22 2018

Is it consistently reproducible for you? If you open multiple tabs to that page, do they all fail to paint?

Comment 29 by kmeis...@gmail.com, 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.
Screen Shot 2018-06-23 at 10.46.08 a.m..png
538 KB View Download

Comment 30 by vincent....@gmail.com, 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)

Comment 31 by zxiaoyu...@gmail.com, Jun 25 2018

Hi I've this problem as well on 69.0.3469.2, 10.14 Beta (18A314h).

On the right hand is in Safari, which works perfectly.
Screen Shot 2018-06-24 at 10.16.18 PM.png
46.3 KB View Download

Comment 32 by craigtumblison@chromium.org, Jun 25 2018

Labels: Hotlist-ConOps

Comment 33 by vincent....@gmail.com, Jun 26 2018

Hi, it's fixed for me in version 69.0.3473.0 :)

Comment 34 by e.andthe...@gmail.com, Jun 27 2018

It was fixed in a couple versions for me and now it's broken again in Canary 69.0.3473.0

Comment 35 by rsesek@chromium.org, 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.

Comment 36 by harrison...@gmail.com, Jun 28 2018

I tried changing that flag in the latest Dev release and it fixed it for me.

Comment 37 by ellyjo...@chromium.org, Jul 2 2018

Cc: nyerramilli@chromium.org ellyjo...@chromium.org rbasuvula@chromium.org
 Issue 857457  has been merged into this issue.

Comment 38 by markusma...@gmail.com, Jul 3 2018

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

Comment 39 Deleted

Comment 40 Deleted

Comment 41 by montog...@gmail.com, Jul 4 2018

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

Comment 42 by montog...@gmail.com, Jul 4 2018

Just tried activating Mac V2 Sandbox flag. It doesn't work neither in Beta or Canary.

Comment 43 by kmeis...@tucowsinc.com, Jul 4 2018

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.
Screen Shot 2018-07-04 at 8.59.07 a.m..png
140 KB View Download

Comment 44 by vincent....@gmail.com, Jul 5 2018

Still broken with Canary 69.0.3482.0 and the beta 3 build 18A326g ("Mac V2 Sandbox" enabled or disabled).

Comment 45 by tkent@chromium.org, Jul 9 2018

 Issue 861615  has been merged into this issue.

Comment 46 by tkent@chromium.org, Jul 9 2018

 Issue 861693  has been merged into this issue.

Comment 47 by rsesek@chromium.org, Jul 9 2018

Cc: markchang@chromium.org jawag@chromium.org
 Issue 857401  has been merged into this issue.

Comment 48 by bugdroid1@chromium.org, Jul 10 2018

Project Member
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

Comment 49 by nigel.l....@gmail.com, Jul 10 2018

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

Comment 51 by vincent....@gmail.com, Jul 11 2018

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)
100%.png
53.3 KB View Download
100.1%.png
58.0 KB View Download

Comment 52 by nigel.l....@gmail.com, Jul 12 2018

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

Comment 53 by nigel.l....@gmail.com, Jul 18 2018

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

Comment 54 by harrison...@gmail.com, Jul 18 2018

This seems to be solved with 69.0.3493.3 and macOS 10.14 Beta 4.

Comment 55 by vincent....@gmail.com, Jul 19 2018

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."

Comment 56 by nigel.l....@gmail.com, Jul 22 2018

not fixed for me with 68.0.3440.68 (beta) and 18A336e
However it seems fixed in canary 70.0.3499.0 for me

Comment 57 by alexej.k...@gmail.com, Jul 22 2018

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

Comment 58 by vincent....@gmail.com, Jul 23 2018

It seems to be corrected since 2-3 builds but the rendering is not the same with a zoom 100% and 90%/110%

Comment 59 by ellyjo...@chromium.org, Jul 23 2018

#58: Yup, that is a known behavior in WebKit-based browsers - Safari has it as well.

Comment 60 by rsesek@chromium.org, Jul 23 2018

Status: Fixed (was: Assigned)

Comment 61 Deleted

Comment 62 by rsesek@chromium.org, Jul 26 2018

 Issue 867936  has been merged into this issue.

Comment 63 by rsesek@chromium.org, Jul 30 2018

Cc: rsesek@chromium.org
 Issue 868883  has been merged into this issue.

Sign in to add a comment