Monaco's context menu should not get clipped at container or browser boundaries

monaco-editor version: 0.8.3
Browser: Any
OS: Windows 10
During Accessibility testing, one of the tests performed for the visually impaired is to check that a site is still functional (though not necessarily pretty) at 200% browser zoom on a typical/low-end monitor with no other OS scaling.  An issue found was that Monaco's context menu can become clipped either by the edge of the browser window, or by the container hosting Monaco if it is styled with overflow:hidden.
A common pattern to avoid this is to append the context menu container to the BODY element rather than within the Monaco container, and use absolute positioning relative to the window.  This gets it out of the Monaco container, so overflow styles do not affect it.  Also, it should get a vertical scrollbar if needed (overflow-y auto) if it does not fit within the bounds of the browser window.  Shown below is the Monaco playground, zoomed at 200%, with the menu getting clipped at the bottom of the browser window (figure 1).  Following that is the same but with a height put on the menu at the boundary and a scrollbar, slightly scrolled down, so that all menu items can still be accessed (figure 2).
Figure 1:  Monaco at 200% with clipped menu and inaccessible menu items.

Figure 2:  Menu with a set height and vertical scrollbar.

@alexandrudima , here is another issue to be considered that affects accessibility according to our testing for VSTS.  I appreciate all your work on these.

Version 0.9.0
Browser: any
OS: Windows 8.1
Here's another image showing the clipped menu.
The blue lined container has an overflow:hidden style applied.
That is, if any container at any level has an overflow:hidden style, the context menu/suggesstion/widgets/... is clipped at the containers boundaries.

Possible fix besides the one mentioned by @jayspadie:
Use fixed positioning instead of absolute one on any of those widgets and calculate the position related to the document boundaries.
Thanks for your effort!

@alexandrudima Is there any option to bring those autocomplete dropdowns out of the normal flow so that they work inside overflow: hidden element also?

an alternative approach might be to used position: fixed and trick the context-menu that way to leave it's parent boundaries
this.editor.onContextMenu((e) => {
      const contextMenuElement =  this.editor.getDomNode().querySelector(".monaco-menu-container") as HTMLElement;

      if (contextMenuElement) {
        const posY = (e.event.posy + contextMenuElement.clientHeight) > window.outerHeight
          ? e.event.posy - contextMenuElement.clientHeight
          : e.event.posy;

        const posX = (e.event.posx + contextMenuElement.clientWidth) > window.outerWidth
          ? e.event.posx - contextMenuElement.clientWidth
          : e.event.posx;

        contextMenuElement.style.position = "fixed";
        contextMenuElement.style.top =  Math.max(0, Math.floor(posY)) + "px";
        contextMenuElement.style.left = Math.max(0, Math.floor(posX)) + "px";
      }
    })

depending on your use-case you might have to fiddle around with the checked boundary, in my case it is an electron app, where the border is the windows outer height/width

I have, I believe, a similar issue with Hover Provider popups.  If the monaco editor instance is inside of an element with something like "overflow: auto", then when I hover over something that has a registered HoverProvider, the "monaco-editor-hover" popup is clipped, or in some cases, completely hidden.

I don't believe this is an issue any more.  The context menu repositions and adds a scroll bar as necessary now.  (The scroll bar does not work currently, there is a PR for it though.)

How is this still not an issue? I have an overflow: auto parent that clip context menu. And looks like fixedOverflowWidgets have no effect on context menu.

Then latest release shipped with fixes here and seems to have resolved the issue.

  This was a problem for our software running on smaller screens, and the upgrade to 0.21.2 seemed to fix the issue, as @sbatten mentioned.


chore: bugfixes and API updates for preview integration

Note that this requires some NDMF changes that have not yet been released. Test using latest main branch.

Note that some of the change notifications might be unnecessary; this is a very rough PR, but it seems to work. Kind of.

Thank you for PR! I've updated the branch with more recent API changes so I'm closing this PR.


SNOW-1475324: Snowpark that enables the ingestion of data from ODBC/JDBC-based sources

What is the current behavior?
customer would like to ingest data tables into snowflake
What is the desired behavior?
currently the data source support jdbc/odbc drivers for connection
How would this improve snowflake-snowpark-python?
the ability to import diverse data source into snowflake/snowpark for further integrated processing
References, Other Background

Hello @em47390 ,
Thanks for raising the question.
Using Snowflake's JDBC or ODBC connectors is more straightforward for simple data ingestion tasks such as in this case. You can use these connectors to ingest data directly from ODBC/JDBC-based sources into Snowflake efficiently.
Where as Snowpark is a developer framework provided by Snowflake that allows you to write code in languages like Scala, Java, and Python to interact with Snowflake data. It provides a way to build complex data pipelines, transformations, and analytical applications within the Snowflake environment.
So, I would recommend using Snowflake jdbc and odbc connectors for data ingestion in this scenario.
Regards,
Sujan

Hello @em47390 ,
We provided recommendations, closing this issue.
Regards,
Sujan

Hello @em47390 ,
Thanks for raising the question.
Using Snowflake's JDBC or ODBC connectors is more straightforward for simple data ingestion tasks such as in this case. You can use these connectors to ingest data directly from ODBC/JDBC-based sources into Snowflake efficiently.
Where as Snowpark is a developer framework provided by Snowflake that allows you to write code in languages like Scala, Java, and Python to interact with Snowflake data. It provides a way to build complex data pipelines, transformations, and analytical applications within the Snowflake environment.
So, I would recommend using Snowflake jdbc and odbc connectors for data ingestion in this scenario.
Regards, Sujan

Thank you Sujan!! We'll bring thesuggestion back and discuss further!


How to block an ip address

I'm the trying to do the opposite. Is there a way to blacklist ip addresses versus whitelisting them?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d90bbf62-44f9-30a6-d6ea-bbf776f6efc5
Version Independent ID: b3961eac-6c70-b345-f48c-e4c0ec67059c
Content: Azure App Service IP Restrictions
Content Source: articles/app-service/app-service-ip-restrictions.md
Service: app-service-web
GitHub Login: @btardif
Microsoft Alias: byvinyal

We are working on adding more functionality to this feature include allow/deny lists. Can't comment on timeline but it's work in progress.


TO GO unit tests: request change from submitted to complete is valid

change needed after #2271

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/1675/
Test PASSed.


Update dependency to latest Xamarin.Firebase.Messaging

🚀 Update dependency to latest Xamarin.Firebase.Messaging
A lot of dependencies have changed and removed in the latest version of Xamarin.Firebase.Messaging.
FirebasePushNotificationPlugin seems to have a lot more dependencies than it needs to work.
Support for the latest Xamarin.Firebase.Messaging 122.0.0
Plugin.FirebasePushNotification depends on Xamarin.Firebase.Messaging (>= 71.1740.0)
Platforms affected (mark all that apply)

[ ] :iphone: iOS
[x] :robot: Android
[ ] :checkered_flag: WPF
[ ] :earth_americas: UWP
[ ] :apple: MacOS
[ ] :tv: tvOS
[x] :monkey: Xamarin.Forms

Same request.


feat: bump swapper to latest

Description

Notice

[ ] Have you followed the guidelines in our Contributing guide?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #
Risk

Testing

Engineering

Operations

Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #2877

PR #2872

PR #2842

PR #2885

PR #2887   👈

This comment was auto-generated by Graphite.


Sync not working

Is there a deck # limit?
Chrome: Version 75.0.3770.142
iMac with Sierra 10.12.6
Sync tool V0.3
Finds all decks in my Vault account: 289 COTA and AOA
Moving to DecksofKeyforge there are no decks listed and pressing SYNC creates and error screen of: No decks accessed from Master Vault. Click "Access Master Vault" first. Tried using same window in chrome and different tabs in chrome. No Luck.

There is unfortunately a limit to how much data Chrome will allow an extension to write at once (saving the "library"). I'm not sure of the exact limit but somewhere north of 180-200+ decks seems this error starts occurring. I've found a way to chunk out the write, going to try and see if that resolves this issue, hopefully have a fix for this sometime later this week.

I tried to use a class I found that supposedly addresses this issue by chunking your data into smaller writes but still hit the quota. So next I tried writing a record for each deck instead of a giant blob, but THAT hits the max writes per minute quota. Need to do some research to figure out how people get around this...

I know this issues already on your list, Torres, but I'm going to bump this thread anyway. (260+ decks trying to import to (any) of the supported sides.)

I have a pull request (https://github.com/funkymonkeymonk/library-access/pull/3/files) that should fix this issue. However, since I can only simulate the problem I'd love it if someone that actually has this problem could check it out and see if this code fixes it.

David,
It does the same thing for me. Do I need to do a re-install of the app?
Scot
On Thu, Aug 22, 2019 at 11:27 AM David Torres<EMAIL_ADDRESS>wrote:

I have a pull request (
https://github.com/funkymonkeymonk/library-access/pull/3/files) that
should fix this issue. However, since I can only simulate the problem
I'd love it if someone that actually has this problem could check it out
and see if this code fixes it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/funkymonkeymonk/library-access/issues/2?email_source=notifications&email_token=AK77PFRVYVKNGW2H3BDTISLQF2V7HA5CNFSM4IHNSFQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD45OXDI#issuecomment-523955085,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK77PFVJKKVTRBSUKWR7MK3QF2V7HANCNFSM4IHNSFQQ
.

I'm able to hit the extension while on Master Vault, and it tells me it scooped up the decks, but when I return to a site to import what's been slurped up, no dice.

Sorry, to be clear here, I have not published a new version, I'm talking specifically about the development version posted here. You'd have to be following the installation instructions in the README. Otherwise, just hang tight, a new version will be published soon.

 I'm excited, obviously, and jumped the gun. IGNORE ME (hastag venturebrothers)

0.4 let me load in 305 decks from the Vault into DOK! Thank you.

Awesome was just about to post that I published the new version last night. Glad to hear the issue is confirmed to be fixed.


Bug: /info endpoint doesn't return LoggingDriver in 1.6

In 1.6.0-rc5 I can confirm that /info endpoint does not return any LoggingDriver (the field is just missing).
Repro steps.

Start docker daemon with sudo docker -d -H unix:// -H <IP_ADDRESS>:4243
curl http://localhost/info | grep LoggingDriver
Shows nothing, supposed to show "LoggingDriver" : "json-file".

This is a bug since this field was documented in Remote API docs and CLI outputs for Docker 1.6 docs.
Also reproes even though you explicitly add --log-driver=json-file to the daemon arguments.
Fix
My change #12226 fixes this. I can't exactly tell how it does. I didn't investigate it thoroughly. It just improves handling of logging driver types and their lifecycle.
cc: @LK4D4 @crosbymichael

Added test #12231 to verify this is the case but apparently this doesn't occur in test environment.
In my ps output I see docker started as:
docker -d --log-driver=json-file -H unix:// -H tcp://<IP_ADDRESS>:4243

however curl/docker info doesn't return any logging driver info to me for some reason.
$ docker -v
Docker version 1.6.0-rc5, build fc4825d

That patch was added after the fact I believe so I think it is only in
master
On Thu, Apr 9, 2015 at 4:20 AM, Ahmet Alp Balkan<EMAIL_ADDRESS>wrote:

Added test #12231 https://github.com/docker/docker/pull/12231 to verify
this is the case but apparently this doesn't occur in test environment.
In my ps output I see docker started as:
docker -d --log-driver=json-file -H unix:// -H tcp://<IP_ADDRESS>:4243
however curl/docker info doesn't return any logging driver info to me for
some reason.
$ docker -v
Docker version 1.6.0-rc5, build fc4825d
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/12229#issuecomment-91198814.

confirmed, only in master

so I think this is fine it works on master

@jfrazelle are we cherrypicking to release for the next rc?

nope I do not think its necessary, it was an added "nice to have" but not
essential or fixing a bug
On Thu, Apr 9, 2015 at 10:57 AM, Ahmet Alp Balkan<EMAIL_ADDRESS>wrote:

@jfrazelle https://github.com/jfrazelle are we cherrypicking to release
for the next rc?
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/12229#issuecomment-91310654.

@jfrazelle hmm then we need to remove it from the docs and cherry pick into the 1.6 docs release so that it wont mention this field.

It's not in the docs on my branch :), this is why I also don't cherry pick
docs commits
On Thu, Apr 9, 2015 at 11:03 AM, Ahmet Alp Balkan<EMAIL_ADDRESS>wrote:

@jfrazelle https://github.com/jfrazelle hmm then we need to remove it
from the docs and cherry pick into the 1.6 docs release so that it wont
mention this field.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/12229#issuecomment-91312458.

sooooo closing


[Feature]: Show the number of tabs on the header for list of tabs in property pane

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
When working with tabs widget and there are a lot of tabs, i want to see the number of tabs so that i know there are more tabs which can be scrolled to access
Why should this be worked on?
Helps users not get confused with regards to the data in tabs

Solution
Add the number of tabs present besides the tabs label

@dilippitchika I would like to work on this issue, please assign it to me?

Greetings @rksingh2001 , thanks for showing interest 🎉 , This is all your. Assigning this to you now.
Please don't forget to read the Contribution Guidelines. Would appreciate if you can open a PR within the next 2 days. let us know here

I would also like to work on this, Please assign it to me.

Hey @Subhamjain02 @AbhishekTiwari23 thanks for showing your interest. Since @rksingh2001 hasn't gotten back to us yet, i would like to wait for one more day and assign it to one of you.

Hey @Subhamjain02 @AbhishekTiwari23 thanks for showing your interest. Since @rksingh2001 hasn't gotten back to us yet, i would like to wait for one more day and assign it to one of you.

Ok, I am waiting

if  no one take it.. can i grab this issue? @dilippitchika

if no one takes it.. can I grab this issue? @dilippitchika

Actually, someone is already working on this issue

ooo sorry dude, i didn't see u was assigned

Hi @AbhishekTiwari23 @tauantcamargo @Subhamjain02, Assigning this to you all 3 of you now. Since we haven't heard back from @rksingh2001. If one of you can submit a PR we should be able to close this quickly. Please check out other good first issues if you are unable to contribute to this.
Please don't forget to read the Contribution Guidelines. Would appreciate if you can open a PR within the next 2 days. let us know here

Is there anyone still working on it?

Hello @AnuragThePathak i have assigned a few folks who were willing to work on it. Do you also want to work on this issue?

If they are already working then it's fine.

Ok, please let me know if you find any other issues you want to work on

Sure I'll

Hey, Can I work on it?


rust-analyzer: 2021-12-27 -> 2022-01-31

Motivation for this change
Update to the latest release
https://github.com/rust-analyzer/rust-analyzer/releases/tag/2022-01-31
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review run on x86_64-linux 1

3 packages built:

rust-analyzer
rust-analyzer-unwrapped
vscode-extensions.matklad.rust-analyzer

Result of nixpkgs-review pr 157908 run on aarch64-darwin 1

3 packages built:

rust-analyzer
rust-analyzer-unwrapped
vscode-extensions.matklad.rust-analyzer


Add set of "custom" configs to bp_common_aviary_pkg

The aviary is rapidly approaching carrying capacity.  There are a few ways to reduce the number of configs which require significant rewrites.  A simple way which is good for the long term:
bp_custom_config_0 =
{
  num_core = `BP_CUSTOM_0_NUM_CORE
  num_lce = `BP_CUSTOM_0_NUM_LCE
...
etc.
}

bp_custom_config_1 =
{
  num_core = `BP_CUSTOM_1_NUM_CORE
  num_lce = `BP_CUSTOM_1_NUM_LCE
...
etc.
}

Then, a testbench which is using a "weird" configuration can set all of these variables via macros.  We only need probably 2 custom configs to start because I doubt anyone is going to do more than parrot.PARROTLET (okay, I'll stop with the bird puns).

Fixed by #591