sync - #1
Open
ca333 wants to merge 1647 commits into
Open
Conversation
yurii-khi
pushed a commit
that referenced
this pull request
Jun 1, 2023
fix(android): compatibility with android 13 (sdk 33)
…tions in favor of _pickFiles helper
…d and error listener
Tika added ~300 KB to the Android binary just to detect a MIME type in saveFile(). MIME types are now resolved from the file name extension via MimeTypeMap, with URLConnection.guessContentTypeFromStream as a content-sniffing fallback when no usable extension is available. Fixes #2101
… detection Tika added ~300 KB to the Android binary just to detect a MIME type in saveFile(). MIME types are now resolved from the file name extension via MimeTypeMap, with URLConnection.guessContentTypeFromStream as a content-sniffing fallback when no usable extension is available. Fixes #2101
Co-authored-by: Navaron Bracke <brackenavaron@gmail.com>
feat(web): extract file_picker_web package
Trims the "(and previously Apache Tika)" and "without pulling in a full content-detection dependency" asides per review feedback - they only make sense with context that won't exist once Tika is fully removed from the codebase.
- Revert the version bump: file_picker_android hasn't been published yet, so there's no prior release to patch against. - Fold the CHANGELOG entry into the existing 1.0.0 heading instead of a new 1.0.1 section. - Drop stale Tika references from doc comments, same as the companion android/ fix.
…cker-android fix(file_picker_android): remove Apache Tika dependency for MIME type detection
fix(android): remove Apache Tika dependency for MIME type detection
#2104 merged before this correction landed on that branch. This fix targets the v11.x hotfix release, so the CHANGELOG entry belongs under its own 11.0.3 heading (positioned above 11.0.2 to match release chronology), not the unreleased 12.0.0-beta.8 bucket.
docs: attribute Tika removal to the 11.0.3 hotfix
…indow The note was buried under parentWindow and understated the practical consequence. lockParentWindow behaves differently depending on the session: under X11 the XID is obtainable and the dialog is genuinely modal, under Wayland the portal wants an xdg_foreign handle that Flutter does not expose, so the dialog stays unparented and the option has no visible effect. Wayland is the default on current desktops, so that is the common case, not an edge case. Also notes the XWayland route for anyone who needs real modality today.
Verified end to end on XWayland: xdotool getactivewindow returned 25165834, the portal received parent_window "x11:0x180000a", and the parent window was genuinely blocked while the dialog was open. The previous snippet suggested looking the XID up from a shell, which is not usable: it changes on every run, so it has to be read at runtime. Replaced with the runtime version, and said plainly that depending on xdotool is not good for a shipped app but is the only option today.
The example only registered the implementation. It now shows the part that is not obvious from the API: lockParentWindow reaches the portal as modal, but the portal also needs parentWindow to know which window to be modal against, and Flutter exposes no API for that handle. Kept in this package's own example rather than the shared example app, since referencing FilePickerLinuxOptions means importing file_picker_linux, which has no business being imported from cross platform demo code.
The example was a single example.dart that could not run: it imports file_picker_linux, which pulls in package:flutter, so `dart run` dies on `dart:ui is not available on this platform`. That was true of the original too, those files exist for pub.dev's Example tab and Pana's score, not to be executed. Replaces it with a real Flutter app for Linux, with the runner scaffold, that demonstrates the thing the API does not make obvious: lockParentWindow reaches the portal as modal, but the portal also needs parentWindow to know which window to be modal against. Both are switches in the app, so the difference can be observed directly, and the header points at dbus-monitor for watching what actually goes over the wire. Registered in the root workspace and in melos packages so the workspace resolves it and CI analyzes and tests it. Melos's test script fails a package that has no test directory, so the app ships with widget tests rather than being excluded. Verified with `flutter build linux`, `melos exec -- flutter analyze .` across all 9 packages, and `melos run test`.
The example and the README both used `xdotool getactivewindow`, which is wrong in the exact situation this is meant to demonstrate. With XWayland running it does not fail on a Wayland session, it returns the focused X window, which belongs to some other application. Verified here: it returned VS Code's window (WM_CLASS "code"), so the portal was being asked to parent the dialog to the editor, and nothing got locked. Searching for a visible X window owned by this process returns nothing when the process has none, which is the correct answer on a native Wayland session. The app now probes on startup and says up front whether a parent window was found, so the reason a dialog is not modal is visible before picking rather than inferred afterwards. The resolver is injected so widget tests do not spawn a process. The previous tests failed with a pending timer for that reason, and the injection also lets them cover both the X11 and the Wayland outcomes.
…app" Goes back to example/example.dart being example code, in line with the other six packages, instead of a full Flutter app with its own runner scaffold, pubspec and workspace entry. Keeps the correctness fix that came out of building it: resolve the parent window by searching for an X window owned by this process, not with xdotool getactivewindow, which on a Wayland session returns the focused X window belonging to another application. Reverts the root pubspec too, so the workspace list and the melos packages glob go back to what they were.
The tests defined their own copy of the narrowing switch, so they proved nothing about the implementation. Breaking the real code left them green. The switch was also duplicated across all three entry points. It is now a single `FilePickerLinux.resolveOptions`, marked visibleForTesting, that the three call sites share and the tests exercise directly. Checked that this actually bites: reintroducing the original bug in the implementation now fails two tests, where before it failed none.
Address review: the arrow body spanned six lines, a block body reads better.
fix(linux): stop dropping options passed as plain LinuxOptions
…epresentation-changelog # Conflicts: # packages/file_picker_linux/CHANGELOG.md
…tation-changelog chore: prepare next release across all packages
…verything Today six of seven publish runs got cancelled seconds after being created while releasing every package at once, only the seventh (the one whose tag happened to land last) actually ran. The cause: the whole workflow shared a single concurrency group across both jobs, so a prepare run that has been stuck queued since an earlier session sat in that same group and, once seven publish runs piled up behind it in a few seconds, GitHub cancelled the backlog instead of queueing it. prepare and publish now each get their own concurrency group, and publish's group is scoped to the triggering tag, so different packages' publish runs are fully independent of each other and of prepare. A stuck prepare run can no longer take any publish down with it.
… it pins The facade required file_picker_platform_interface ^3.2.0 while still allowing implementations published against ^3.0.0, which predate the DarwinOptions parameter added in 3.2.0. Every constraint was satisfied and the result did not compile. Four of the five lower bounds were wrong, not just Windows as reported. Confirmed by resolving a clean project at the minimum allowed versions: the interface came out at 3.2.0 alongside android 1.0.0, linux 1.0.0, web 3.0.0 and windows 1.0.0, all of them built against ^3.0.0. No implementation needs republishing, they are all correct on pub.dev. Only the facade's bounds were stale. Adds tool/check_facade_constraints.dart, run in CI, which compares each lower bound against the first published version of that implementation built against the interface the facade pins. Verified that it reports all four against the previous pubspec and passes against this one. It warns and skips rather than failing when pub.dev is unreachable, since it is a safety net and should not block unrelated pull requests. Fixes #2186
Bumps the actions group with 1 update: [actions/setup-java](https://github.com/actions/setup-java). Updates `actions/setup-java` from 5 to 6 - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@v5...v6) --- updated-dependencies: - dependency-name: actions/setup-java dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major dependency-group: actions ... Signed-off-by: dependabot[bot] <support@github.com>
…actions-31df092e2e chore(deps): bump actions/setup-java from 5 to 6 in the actions group
This reverts commit 9afdc1d.
… smoke test Address review: the custom tool modeled the bug (hand-rolled YAML and semver parsing, comparing declared constraints against pub.dev metadata) instead of reproducing it. A parsing bug could pass while the real resolution still does not compile, which is exactly the false confidence the tool existed to prevent. Replaced it with what actually happens to an external consumer: a standalone app outside this workspace depends on the facade via a path dependency, so its other dependencies resolve from pub.dev instead of the local checkout, then `pub downgrade` forces every one of them to the lowest version its constraint allows. `flutter analyze` does not catch this, a plugin's platform-specific implementation is only pulled into the type-checked graph through the generated plugin registrant, which only a real build produces. `flutter build web` does, and empirically catches every platform's implementation at once (not just web's), since dart2js compiles the whole registrant regardless of which platform each implementation targets. Verified in both directions: fails with the exact error from #2186 against master before this PR, passes against this branch.
…rrency-scope fix(ci): scope publish concurrency per tag instead of one group for everything
…constraints fix(file_picker): require implementations built against the interface it pins
…workaround Confirmed fixed against AmrTawfek's real project in #2170. Reframed the changelog and added a code comment: general Gradle guidance discourages pinning an older AGP via a module's own buildscript classpath while the consuming app applies a newer one through the plugins block, which is why #2154 removed this in the first place. Restoring it works around a gap in Flutter's own AGP 9 newDsl migration (flutter/flutter#180137), still in progress, not a permanent fix.
…er_file_picker The repository was transferred from miguelpruivo/flutter_file_picker. Updated homepage/repository/issue_tracker in every package's pubspec.yaml, the podspec, the READMEs, the issue template, and the one hardcoded link in CI. Left CHANGELOG.md entries alone, they're a historical record. GitHub redirects the old owner, and pub.dev's Automated Publishing trust has already been repointed separately.
…pt-classpath fix(android): restore the buildscript classpath as a temporary AGP 9 newDsl workaround
Rewrites the 153 issue, pull and wiki links across the changelogs from miguelpruivo/flutter_file_picker to vicajilau/flutter_file_picker. They already worked through GitHub's redirect, this just stops them relying on it. Adds a Credits section to the root and facade READMEs. The facade one is what pub.dev renders, so it is the copy most people will actually see. Deliberately left alone, since neither is a reference to where the repository lives: - the copyright line in the eight LICENSE files, the podspec author field and the header in example/ios/Runner/File.swift, which are authorship and not ownership - the miguelruivo.flutter.plugins.filepicker channel names and the com.mr.flutter.plugin.filepicker namespace, which are identifiers that have to match between Dart and native and would break every app using the plugin if renamed
The first version read like a changelog entry. This one says what he actually built and closes by thanking him. Kept the numbers approximate on purpose. Exact release and download counts would be wrong within the week, the scale is the point.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.