Fix urlbar style #1
Merged
Conversation
This file contains 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
多分この３つが原因なので、修正させていただきます。検証が完了次第マージいたします |
|
私も修正終わったので更に上書きしますね。URLバーのバグは完治しました。 ただ、GTKテーマとの互換性はないようです。バージョンによって異なるので、なんとも言えませんがね。 |
surapunoyousei
pushed a commit
that referenced
this pull request
Aug 14, 2022
Automatic update from web-platform-tests
Make popups animation-friendly
Now, popups will follow this process when showing/hiding:
showPopup():
1. Move the popup to the top layer, and remove the UA display:none
style.
2. Update style. (Transition initial style can be specified in this
state.)
3. Set the :top-layer pseudo class.
4. Update style. (Animations/transitions happen here.)
hidePopup():
1. Capture any already-running animations via getAnimations().
2. Remove the :top-layer pseudo class.
3. Update style. (Animations/transitions start here.)
4. If the hidePopup() call is not due to a "force out" situation,
getAnimations() again, remove any from step #1, and then wait here
until all of them finish or are cancelled.
4. Remove the popup from the top layer, and add the UA display:none
style.
5. Update style.
See this issue for more details:
openui/open-ui#335
Bug: 1307772
Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688871
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1014235}
--
wpt-commits: 297b9403e0ab65348de01169d1a4e3cf078af7b9
wpt-pr: 34304
9 tasks
9 tasks
9 tasks
surapunoyousei
pushed a commit
that referenced
this pull request
Oct 28, 2024
…indows r=win-reviewers,gstoll a=RyanVM This implements PresentSystemSettings, LocationIsPermittedHint and SystemWillPromptForPermissionHint for Windows. The Windows APIs are not always available -- some are currently only available in Windows 11 Canary builds (slated for September release). In the event that APIs are not available, this should do nothing. At present, this is detailed here: https://learn.microsoft.com/en-us/windows/win32/nativewifi/wi-fi-access-location-changes There are two issues that this is intended to handle: 1. The system will display a one-time (or so) dialog to the user when Firefox requests geolocation but doesn't have permission. For that case, we inform the user that they will be asked to grant location permission again. This system dialog is only presented in versions of Windows that support all of the relevant APIs. 2. We open system settings to the right page and post a cancelable modal dialog on the tab if the user grants geolocation to the page but geolocation permission isn't currently granted in the OS. This case will not happen if case #1 did. Unfortunately, we can't get information about the permission status without a location request on old versions of Windows, so this also does nothing unless the recent APIs are supported (in this case, AppCapability::CheckAccess). This work is necessitated not only by the new (occasional) system dialog but also by Microsoft's plans to block wifi scanning if geolocation isn't available. We have used wifi scanning as part of a fallback when system geolocation isn't available -- that approach is no longer viable here. A user would confusingly get repeated errors or very poor results (e.g. IP lookup results) without information as to why, if that happened. This is what happens in the current Windows Canary build if system geolocation is turned off. The fallback remains useful on other platforms, although Linux is in flux (but it is not in the scope of this bug). Differential Revision: https://phabricator.services.mozilla.com/D216474
surapunoyousei
pushed a commit
that referenced
this pull request
Nov 23, 2024
…a=dmeehan This fixes four issues: 1. The test didn't provide enough movement to generate a drag session on the source before moving to the target. This meant that, when they were in different windows, Gecko wouldn't send dragleave to the source or dragenter to the target. It also never sent dragenter to the source in the first place. This remedies that. 2. dragenter and dragleave weren't properly handled because the test was sending dragleaves instead of dragexits (the latter being what Gecko expects and the former being synthesized from that -- see e.g. nsNativeDragTarget::DragLeave). This now uses dragexits and sets the proper expectations. 3. expectProtectedDataTransferAccess was needlessly complicated and, after #1, gave the wrong answers for some events like dragenter called on the source. 4. The event handler wasn't checking for exceptions and the drop handler was intentionally causing one, which was causing it to miss the rest of its execution. Original Revision: https://phabricator.services.mozilla.com/D219550 Differential Revision: https://phabricator.services.mozilla.com/D227589
9 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
変更点
・ライトテーマ時のアドレスバーのスタイル修正