Thanks for working on this! Looks like the logger needs some tweaks from the try. I haven't taken a deep look at the patch. I'm going to be unavailable for reviews in the upcoming days. @mcarare, it looks like you might have context here from the history, if you don't mind taking over the review!

This patch is trying to fix an animation issue with the keyboard pushing the dialog up in a high-motion sort of way on PDF signatures. Originally, the dialog launches and the keyboard pushes it up. The behavior before this patch is bad for motion sickness and visual movement reasons.

Thanks!

Thanks!

Thanks, found the thing I wanted to double check at: https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/print/PrintManager.java;l=518-519 (leaving it here for future visibility).

Add comment

Fix lints try

Fix UI Tests New try

In D328569#11565854, @kaya wrote:

LGTM.

nit - for visibility of the decision:
Looking at the code, I believe when we navigate to another PDF within a PDF, this patch will first hide the tools and then reappear. Have we tested that and is this accepted?

Latest try for stack: https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=103674

Rebase + rearange stack order

Rebase + rearange stack order

Rebase + rearange stack order

This is mostly ready, but I want to do a little more manual testing on it and think over the keyboard conditions more.

Thanks!

Just leaving a note that I double checked that each of nightly, beta, release, and debug all have the right defaults when testing the try artifact APKs. (Mostly double checking since geckoview.fml.yaml isn't commonly used.)

#data-classification-low: This is technical and interaction data. The duration can be influenced by many external factors and all strings are enumerated set bucket values.

In D332816#11563921, @bea wrote:

I am currently working on getting try access: https://bugzilla.mozilla.org/show_bug.cgi?id=2080753, however for now if possible @ohall would you mind running it for me? Thanks!

Thanks for working on this! I want to double check and test a couple of things here because, IIRC, there was something difficult about getting the context right for printing, There was some check we had to pass in the AOSP print code to continue and the activity delegate was added for this.

Fix typos

Try: https://treeherder.mozilla.org/jobs?repo=try&revision=837accd43a0d4cf19018ea0b78e1abeb953c795d

Awesome, thanks for getting this all situated!

Going to move this out of changes planned since I think the CSS is going to land soon in this release (160). Please don't land automatically without the CSS being in tree (bug 2068989).

Try: https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=102790

Fix lint

Try: https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=102192

This revision changes how Firefox collects data, so it needs a #data-classification tag.

Thanks!!

Yay!

We're going to break this up better to make it easier to land.

Thank you for investigating, r+ GV!

Thank you! Could you also update the docs here on how to enable this stuff in GV for local testing?

Thanks for the review! Just putting this into "Plan Changes" to prevent landing.

Thanks for the Review! (Putting this in "Plan Changes" to prevent landing under the new policy.)

Rebase

Try: https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=97152
Original secret settings patch: https://phabricator.services.mozilla.com/D317625

Thanks!

Try: https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=96232

Nice, I'm always impressed by the easy logical fixes you've uncovered on these!

Nice find!

Rebase + test adjustment try

Makes sense, I see this change has already happened in AC and other places as well.

Thanks for removing these! Exciting that this was automated.

Hi @tthibaud, if you have time, could you take a look at this? I had trouble deciding the correct architecture here, so please let me know what you think and if this seems reasonable! Thanks!

Tagging @jonalmeida as a possible second reviewer. (I wanted a second set of eyes on this originally, it sounds like @jonalmeida already has context!)

Sounds reasonable, thanks!

Makes sense to me! Mostly leaving a comment as a breadcrumb in case this causes a different intermittent in the future. The mock providers send new post locations at certain times, and if the getCurrentPositionJS times change, it might also cause a new set of timing issues.

Makes sense, I also double checked the defaults here. (I kinda think it was supposed to be 60,000, but removing it works too!)

Thanks for working on this one and the earlier discussion on Slack about it!