WAI
Status Update
Comments
ra...@google.com <ra...@google.com>
ra...@google.com <ra...@google.com> #2
[Empty comment from Monorail migration]
[Monorail components: -Platform>DevTools Blink>CSS]
[Monorail components: -Platform>DevTools Blink>CSS]
vi...@google.com <vi...@google.com> #3
Tested the issue on reported chrome version #87.0.4280.00 using Mac 10.13.6 as per the steps in https://crbug.com/chromium/1159587#c0
Steps:
---------
1. Launched chrome and opened devtools
2. Observed that able to add position and top rules.
Attached screen-cast for reference.
@Reporter: Could you please review the attached screen-cast and let us know if we missed anything from our end.
Requesting you to provide a sample URL/file that reproduce the issue, so that it would be really helpful in triaging the issue.
Thanks
Steps:
---------
1. Launched chrome and opened devtools
2. Observed that able to add position and top rules.
Attached screen-cast for reference.
@Reporter: Could you please review the attached screen-cast and let us know if we missed anything from our end.
Requesting you to provide a sample URL/file that reproduce the issue, so that it would be really helpful in triaging the issue.
Thanks
qa...@gmail.com <qa...@gmail.com> #4
Hi, no disrespect, but please forward this to developer who knows CSS and HTML. I have explained the issue perfectly.
ra...@google.com <ra...@google.com> #5
Thank you for providing more feedback. Adding the requester to the cc list.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
se...@gmail.com <se...@gmail.com> #6
[Empty comment from Monorail migration]
[Monorail components: -Blink>CSS Platform>DevTools>Authoring]
[Monorail components: -Blink>CSS Platform>DevTools>Authoring]
se...@gmail.com <se...@gmail.com> #7
As per https://crbug.com/chromium/1159587#c0 , it seems to be a feature request hence marking it 'Untriaged' and requesting someone from Dev to look into it.
Thanks.!
Thanks.!
vi...@google.com <vi...@google.com> #8
This is something we’ve been thinking about. We do want to make DevTools more helpful w.r.t. “inactive” styles, i.e. declarations that are covered but still don’t have any effect due to other declarations or rules — like `left: 42px` on a statically positioned element.
ra...@google.com <ra...@google.com> #9
Making this issue about the originally reported behavior, and filing https://bugs.chromium.org/p/chromium/issues/detail?id=1178508 to track further improvements to “inactive” styles.
se...@gmail.com <se...@gmail.com> #10
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.
Sorry for the inconvenience if the bug really should have been left as Available.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sorry for the inconvenience if the bug really should have been left as Available.
For more details visit
ns...@gmail.com <ns...@gmail.com> #11
[Empty comment from Monorail migration]
Description
We have been updating our alarm app to target Android 12 and ran into some odd behavior with the new
SCHEDULE_EXACT_ALARM
permission.When targeting Android 12 this permission is supposed to be required to set exact alarms, see:https://developer.android.com/training/scheduling/alarms#exact-permission-declare
Problem:
In our testing we have found the following with apps targeting Android 12/API 31:
SCHEDULE_EXACT_ALARM
AndroidManifest permission can still set exact alarms when it is ignoring battery optimizations as per:PowerManager.isIgnoringBatteryOptimizations()
SCHEDULE_EXACT_ALARM
AndroidManifest permission, but has its permission disabled in theAlarms & reminders
app info, can still set exact alarms when it is ignoring battery optimizationsExpected behavior:
SCHEDULE_EXACT_ALARM
permission should not be able to set exact alarms on Android 12 regardless of whether it ignores battery optimizations or notSCHEDULE_EXACT_ALARM
permission, but has the permission disabled by the user in theAlarms & reminders
section, should not be able to set exact alarms on Android 12 regardless of whether it ignores battery optimizations or notWhether a user has set the app to ignore battery optimizations seems odd to be a substitute for the Android documentation :
SCHEDULE_EXACT_ALARM
permission. As perThis documentation suggests that holding this exact alarm permission has some sort of affect on avoiding Android's built-in battery optimization. However, how they are so tied together and one can circumvent entirely the new permission is puzzling.
Also, many alarm & reminder apps direct their users to disable Android's built-in battery optimizations as it often is a problem for alarm apps (see:
PowerManager.isIgnoringBatteryOptimizations()
). This is the most common issue in our app's 40k+ reviews and we're constantly emailed about this (despite attempting to get users to disable the optimizer after installation and other reminders).We have created a sample project that shows this behavior - the project's main features include:
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
PowerManager.isIgnoringBatteryOptimizations()
andAlarmManager.canScheduleExactAlarms()
, as well as sets an exact alarm and determines if it was successful and displays the info to the activity's screenAlarms & reminders
manually in app info, and adding/removingSCHEDULE_EXACT_ALARM
permission in the AndroidManifestWe have shared the files withandroid-bugreport@google.com and they are available here:
https://drive.google.com/file/d/1qWkXg5bXT9c47fYOHwS-ZXc1vOMKJQsq/view?usp=sharing
The above behaviors have been seen on our Pixel 6 running Android 12, and our Samsung S22 running Android 12. One can also see this behavior on several alarm apps targeting Android 12, such as Google Clock, Samsung Clock, and others.
Thanks!