Flutter doctor keeps saying that "Visual Studio not installed"

I'm facing the same issue as #55603, and here's the output of flutter doctor -v:
[√] Flutter (Channel stable, 3.0.3, on Microsoft Windows [版本 10.0.22000.739], locale zh-TW)
    • Flutter version 3.0.3 at C:\SDK\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 676cefaaff (3 days ago), 2022-06-22 11:34:49 -0700
    • Engine revision ffe7b86a1e
    • Dart version 2.17.5
    • DevTools version 2.12.2

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at C:\Users\Donald\AppData\Local\Android\sdk
    • Platform android-32, build-tools 30.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[X] Visual Studio - develop for Windows
    X Visual Studio not installed; this is necessary for Windows development.
      Download at https://visualstudio.microsoft.com/downloads/.
      Please install the "Desktop development with C++" workload, including all of its default components

[√] Android Studio (version 2021.2)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)

[√] VS Code (version 1.68.1)
    • VS Code at C:\Users\Donald\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.42.0

[√] Connected device (3 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [版本 10.0.22000.739]
    • Chrome (web)      • chrome  • web-javascript • Google Chrome 103.0.5060.53
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 103.0.1264.37

[√] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.

But I do have everything installed. Here's the proof:

And here's the result of running .\vswhere -format json -utf8 -latest -prerelease -all from the installer folder:
[
  {
    "instanceId": "de3c93c4",
    "installDate": "2022-06-16T02:22:23Z",
    "installationName": "VisualStudio/17.2.5+32616.157",
    "installationPath": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community",
    "installationVersion": "17.2.32616.157",
    "productId": "Microsoft.VisualStudio.Product.Community",
    "productPath": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\Common7\\IDE\\devenv.exe",
    "state":<PHONE_NUMBER>,
    "isComplete": true,
    "isLaunchable": true,
    "isPrerelease": false,
    "isRebootRequired": false,
    "displayName": "Visual Studio Community 2022",
    "description": "功能強大的 IDE、免費供學生、開放原始碼參與者及個人使用",
    "channelId": "VisualStudio.17.Release",
    "channelUri": "https://aka.ms/vs/17/release/channel",
    "enginePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\Installer\\resources\\app\\ServiceHub\\Services\\Microsoft.VisualStudio.Setup.Service",
    "installedChannelUri": "https://aka.ms/vs/17/release/channel",
    "releaseNotes": "https://docs.microsoft.com/en-us/visualstudio/releases/2022/release-notes-v17.2#17.2.5",
    "thirdPartyNotices": "https://go.microsoft.com/fwlink/?LinkId=661288",
    "updateDate": "2022-06-24T07:12:00.8597685Z",
    "catalog": {
      "buildBranch": "d17.2",
      "buildVersion": "17.2.32616.157",
      "id": "VisualStudio/17.2.5+32616.157",
      "localBuild": "build-lab",
      "manifestName": "VisualStudio",
      "manifestType": "installer",
      "productDisplayVersion": "17.2.5",
      "productLine": "Dev17",
      "productLineVersion": "2022",
      "productMilestone": "RTW",
      "productMilestoneIsPreRelease": "False",
      "productName": "Visual Studio",
      "productPatchVersion": "5",
      "productPreReleaseMilestoneSuffix": "1.0",
      "productSemanticVersion": "17.2.5+32616.157",
      "requiredEngineVersion": "3.2.2159.37022"
    },
    "properties": {
      "campaignId": "976493843.1615860730",
      "channelManifestId": "VisualStudio.17.Release/17.2.5+32616.157",
      "nickname": "",
      "setupEngineFilePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\Installer\\setup.exe"
    }
  }
]

Please help!

Hi @MuTsunTsai, thanks for filing the issue.
It seems a regression issue since it has been fixed on #39067.
Labeling the issue for further investigation from the team.

@huycozy I've repeated all your steps, including completely uninstalling Visual Studio and reinstalling, without any success. The flutter doctor -v ends in the same output. I sincerely suggest that you think about how I may help you diagnosing this issue instead of trying to pretend that the issue isn't there based on your "personal experience" (we're not selling religion here, no).

I sincerely suggest that you think about how I may help you diagnosing this issue

@MuTsunTsai The Flutter team members who do primary issue triage are not domain experts in every single part of the Flutter project. This issue was correctly triaged with the correct labels to route it to the engineers who could investigate further, as was noted above ("Labeling the issue for further investigation from the team."). Routing issues to the correct domain experts is a critical part of how the initial triage process helps diagnose issues.

instead of trying to pretend that the issue isn't there based on your "personal experience"

Attempting to reproduce issues and documenting the results is not "pretending that the issue isn't there", it's gathering and documenting a potentially useful data point about the conditions under which an issue reproduces. It is a standard part of our triage process.
Please take a moment to read our code of conduct before continuing to engage here.

I'm facing the same issue as #55603

Since your vswhere output is non-empty even without -products *, this is unrelated to #55603/#39067.
Since your description has non-ASCII output, it's possible that the workaround in 3.0.2 for the buggy vswhere output encoding is not handling this specific case correctly in some way that causes it to be mis-parsed. (E.g., maybe there's an encoding issue with the last character in the string that causes the JSON to be invalid, rather than just that string.)
Could you:

pipe the output of your vswhere command directly to a file and then post that, so we can get the exact bytes that are being output, since copy/pasting from console may not give the same results, and then (after capturing that file)
try this to see if it is indeed specific to incorrect vswhere encoding.

@stuartmorgan Sure.

Here's my output using Powershell Out-File command: vswhere.zip
Yes, replacing vswhere solves the problem. Now flutter doctor finds my Visual Studio.

/cc @loic-sharma

(Regardless of whether we can fix this output up enough to parse successfully, this demonstrates that we should stop silently dropping JSON parsing errors in the vswhere parsing, and instead error out with a clear message.)

Hmm, year that looked strange but I literally typed
./vswhere -format json -utf8 -latest -prerelease -all > \path\to\new.txt
./vswhere_orig -format json -utf8 -latest -prerelease -all > \path\to\orig.txt

on PowerShell. Piping to Out-File made the same result. Maybe some Windows mess...

Ok, I wrote a very simple program and got these files. These should be the actual output.

new.txt
orig.txt

I leave a program that I used to get these files:
#include <stdio.h>
#include <stdlib.h>
#define BUF 1024

int main(int argc, char *argv[]) {
    if(argc != 3) {
        fprintf(stderr, "Usage: %s <cmdline> <outfile>\n", argv[0]);
        return -1;
    }
    char *cmdline = argv[1], *outfile = argv[2];

    FILE *proc = popen(cmdline, "rb");
    if(!proc) {
        perror("exec");
        return -1;
    }

    FILE *fp = fopen(outfile, "wb");
    if(!fp) {
        perror("fopen");
        pclose(proc);
        return -1;
    }

    while(!feof(proc)) {
        char buf[BUF];
        size_t ret = fread(buf, sizeof(buf[0]), sizeof(buf), proc);
        fwrite(buf, sizeof(buf[0]), ret, fp);
    }

    fclose(fp);
    pclose(proc);
}

Thanks, that's perfect.
The exception with JSON parsing that we're currently dropping for that output is:
Unhandled exception:
FormatException: Unrecognized string escape (at line 16, character 38)
    "description": "�w���A�I�[�v���\�[�X�̋����쐬�ҁA�l�p�̖����ŋ��͂� IDE",

So if we want to actually handle this more comprehensively than erroring out when vswhere gives us code that ends up being invalid JSON when interpreted as UTF-8 (rather than just invalid UTF-8, which the previous PR added handling for), we'd need to do some pre-parsing fixup. E.g., we could just strip out the description line entirely, since it's currently the source of all the issues, and we don't actually use it.

Hello! We're working on a fix to this issue. For now, you can unblock yourself by switching to the "master" Flutter pre-release channel or updating vswhere. Please note that the "master" channel is the bleeding edge and you may encounter bugs. We will update this thread when the fix has landed on the "stable" channel. Please let us know if you have any questions!

Hello, the fix for this issue was released in Flutter v3.0.5. Use flutter upgrade to update your Flutter installation. Please let us know if you run into additional issues!

I confirmed that flutter doctor and the Windows build is now working as expected. Thanks for your quick job!

Confirm issue fixed with the original vswhere.

Hey, I update my flutter to v3.05 today and since then I have been getting the same issue.
My flutter doctor response
`[√] Flutter (Channel stable, 3.0.5, on Microsoft Windows [Version 10.0.22000.795], locale en-IN)
• Flutter version 3.0.5 at C:\src\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision f1875d570e (11 days ago), 2022-07-13 11:24:16 -0700
• Engine revision e85ea0e79c
• Dart version 2.17.6
• DevTools version 2.12.2
[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
• Android SDK at C:\Users\sky\AppData\Local\Android\sdk
• Platform android-31, build-tools 30.0.3
• Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 11.0.11+9-b60-7590822)
• All Android licenses accepted.
[√] Chrome - develop for the web
• Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
[X] Visual Studio - develop for Windows
X Visual Studio not installed; this is necessary for Windows development.
Download at https://visualstudio.microsoft.com/downloads/.
Please install the "Desktop development with C++" workload, including all of its default components
[√] Android Studio (version 2021.1)
• Android Studio at C:\Program Files\Android\Android Studio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.11+9-b60-7590822)
[√] VS Code (version 1.69.2)
• VS Code at C:\Users\sky\AppData\Local\Programs\Microsoft VS Code
• Flutter extension version 3.44.0
[√] Connected device (3 available)
• Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.22000.795]
• Chrome (web)      • chrome  • web-javascript • Google Chrome 103.0.5060.134
• Edge (web)        • edge    • web-javascript • Microsoft Edge 103.0.1264.62
[√] HTTP Host Availability
• All required HTTP hosts are available
! Doctor found issues in 1 category.
`

@Maverick-Wolf Please file a new issue and include your vswhere output.


rp_pico::rp2040_pac::i2c0::RegisterBlock needs to be a smart pointer

newbie here so bear with me. I'm trying to operate the I2C bus while inside a timer_irq_0. In order to do this, I want to pass the pointer to the i2c0 (which is a RegisterBlock) to the interrupt in a mutex controlled static. such as this:
static mut LED_AND_ALARM_AND_DAC: Mutex<RefCell<Option>> = Mutex::new(RefCell::new(None));
Where LedAndAlarmAndDac is defined as follows:
type LedAndAlarmAndDac = (
hal::gpio::Pin<hal::gpio::bank0::Gpio25, hal::gpio::PushPullOutput>,
hal::timer::Alarm0,
mcp4725::MCP4725<hal::I2C<pac::i2c0::RegisterBlock, (hal::gpio::Pin<Gpio26, hal::gpio::Functionhal::gpio::I2C>, hal::gpio::Pin<Gpio27, hal::gpio::Functionhal::gpio::I2C>)>>,
);
When I try to compile the code I get:
static mut LED_AND_ALARM_AND_DAC: Mutex<RefCell<Option>> = Mutex::new(RefCell::new(None)); // c21.out & c25.out
|                                                         ^^^^^^^^^^^^^^^^^ the trait Deref is not implemented for rp_pico::rp2040_pac::i2c0::RegisterBlock
|
= help: the trait _embedded_hal_blocking_i2c_Read is implemented for rp2040_hal::I2C<T, PINS>
= note: required for I2C<RegisterBlock, (Pin<Gpio26, Function<I2C>>, Pin<Gpio27, Function<I2C>>)> to implement _embedded_hal_blocking_i2c_Read
= note: the full type name has been written to '/home/pi/rp-hal-boards/target/thumbv6m-none-eabi/debug/examples/b_blinky-8a6ca0e44c025344.long-type-14025323175658563897.txt'
note: required by a bound in mcp4725::MCP4725
--> /home/pi/.cargo/registry/src/github.com-1285ae84e5963aae/mcp4725-0.4.2/src/lib.rs:60:10
and this is what the compiler long_type-14025323175658563897.txt shows:
rp2040_hal::I2C<rp_pico::rp2040_pac::i2c0::RegisterBlock, (rp2040_hal::gpio::Pin<Gpio26, rp2040_hal::gpio::Function<rp2040_hal::gpio::I2C>>, rp2040_hal::gpio::Pin<Gpio27, rp2040_hal::gpio::Function<rp2040_hal::gpio::I2C>>)>
Which seems just about what I was trying to do without the mcp4725 crate type prefix.
I could possible update the a local crate with a simple Deref function for RegisterBlock but it would seem like most IRQ handlers that want to have access to I2c and other RegisterBlocks would have the same problem. So I'm thinking that maybe this should be fixed in rp2040_pac.
Sorry if it turns out I'm confused about how to declare a mutex static for passing into the IRQ, just a newbie here.
b_blinky_c25_rs.txt
I'm just amending the example in rp-hal/rp2040-hal/examples/vector_table.rs. I don't have any need to change the IRQ handler address but I would like to send info over the I2c to the MCP4725 DAC and change the timer alarm value.
I've attached the whole source code as a txt file hope that helps.
R

Not sure why the whole static definition was not shown above but here it is:
static mut LED_AND_ALARM_AND_DAC: Mutex<RefCell<Option>> = Mutex::new(RefCell::new(None)); // c21.out & c25.out
again. Note that the Option<...> now refers to the type I'm trying to pass. This is the way it was in the source code. Not sure what I copied above.
sorry for any confusion.

The static is not showing properly in this issue it should be:
"static mut LED_AND_ALARM_AND_DAC: Mutex<RefCell<Option>> = Mutex::new(RefCell::new(None)); // c21.out & c25.out"
I placed it in quotes here hoping that would help. 3rd times a charm...

But no that didn't work either Trust me
it looks like .... Option>> = Mutex::new(RefCell::new(None)); // c21.out & c25.out
4th time trying this. I have summarized the prefix with ... and just shown what's on the statement line from Option onwards.

wth? I guess you will need to trust me on this inside the Option<...> chevrons,
is the type LedAndAlarmAndDac

If you put your code between triple backticks it won't get interpreted as markdown directives.
Eg
By putting 3 ` at the beginning and end, github will display this as is: <Magic>

thanks.

Hi, I have a hard time reading through the misformatted message but a thing that seems odd to me is the first type in:
rp2040_hal::I2C<rp_pico::rp2040_pac::i2c0::RegisterBlock, (rp2040_hal::gpio::Pin<Gpio26, rp2040_hal::gpio::Function<rp2040_hal::gpio::I2C>>, rp2040_hal::gpio::Pin<Gpio27, rp2040_hal::gpio::Function<rp2040_hal::gpio::I2C>>)>

It should not be the RegisterBlock type but either rp2040_pac::I2C0 or rp2040_pac::I2C1 which both implement Deref<Target = rp2040_pac::i2c0::RegisterBlock>.

@RayLucchesi: Is your question answered?


Adds banner image below description

Adds the ability to add an optional image to points on the timeline.

Adds bubble specific colors to resolve #14


How to specify /t:PublishContainer in pubxml?

Is it possible to specify /t:PublishContainer in a pubxml file? That way we can run:
dotnet publish /p:PublishProfile=MyContainerProfile.pubxml

Unfortunately this isn't possible - pubxml files only container MSBuild properties and cannot influence what target will be run.


[Xiaomi wired switch] Parse operation mode response

Read response for get query.
Rename key to operation_mode
Rename values to clearer names.

Thanks!


Ring-like error pattern in depth image of plane surface

Required Info

Camera Model
D415

Firmware Version
<IP_ADDRESS>

Operating System & Version
Win 10

Kernel Version (Linux Only)
n.a.

Platform
PC

SDK Version
2.16.1

Language
n.a.

Segment
Robot

Issue Description
We experience a systematic error pattern in the depth image when we arrange the RealSense camera parallel to a large plane surface, see attached images. The error (resp. max. minus min. distance) is in the order of magnitude of one percent of the plane distance. The surface is a matte surface, for the images the emitter was enabled.
We already verified that the error pattern is

independent of the particular camera (see attached image of other D415, we saw this on many different D415 cameras)
independent on the firmware version used (the other camera has firmware version <IP_ADDRESS> installed)
independent of the distance of the plane from the camera
independent of whether the emitter is enabled or not
independent of the parallelity of the plane to the camera (in the false color depth image, the error is, however, not as apparent as with a parallel surface)
independent of the position above the surface (to verify that the surface itself does not show this irregularity, the second image "moving" was shot during slow movement of the robot arm parallel to the surface)

We also used the Depth Quality Tool, which shows that the RMS is completely within the expected bounds (approx. 0.28 % ). However, the regularity of the pattern is what makes us suspicious, and which makes it hard to use the camera for reliable measurements, compared to e.g. white noise in the depth image.
We verified that the intrinsic parameters of the camera are correct, by performing a manual camera calibration using MVTec Halcon with the rectified infrared images, which showed that the distortion of the rectified images is reasonably close to zero.
We verified that the epipolar lines are correct, i.e. chessboard corners have the same y-coordinate in the left and right infrared image.
We did not perform a field calibration of the camera so far, because it is not plausible that a misalignment of the infrared imagers lead to this error pattern (a misaligned camera must lead to a linearly distributed error among the depth image). Also it is not plausible that all D415 cameras we have are consistently miscalibrated.
Has anyone seen this kind of pattern as well? Is there an explanation for the source of this kind of error? How can we eliminate this systematic error?
Steps to reproduce:

take a D415 and a plane surface
align the camera perfectly parallel to the surface
watch the depth image in RealSense viewer

Thanks in advance!

What a detailed post and good job being scientific about the origin of the problem, really great job. I've come across the same pattern in various ways. Once I tried to fit a a plane to the produced point cloud and the pattern is exactly the same.

I suspected that the origin of the problem was radial distortion (radial pattern).
this is the first random paper I came up google-ing radial distortion depth images. Since then I've not found the time to research into stereo pair undistortion, but I think it is still an open problem. A straightforward solution is to calibrate the sensors of the stereo pair as good as possible, but still slight distortion in the cameras would produce wrong disparity -> depth inmho.
If you can come up with something that helps correcting the produced depth, please share :D

Yes what you have observed is correct. It stems from a mismatch between the lens distortion and the ability of the chip to correct for this type of distortion.  There is no fix to it unfortunately. However the D435 and D435i do not exhibit these fine ripples.

@agrunnet have you looked deep into this problem? Can you share more detailed info about this problem, or redirect us to some info? Speaking of our application , we really prefer the D415 device for various reasons (narrow FoV, on chip HW sync among sensors). You state that the chip is not able to correct this kind of distortion, but can it be done in a post-process manner?

Yes some companies have corrected this very fine depth structure by calibration each pixel vs distance to get a correction factor that they then apply and scale each point by but they had to measure at multiple distances. Also it is a per unit calibration correction meaning that cannot be generalized across different units unfortunately. It all stems from a residual aberration in the lenses that our chip rectification model cannot correct for.

I've tried an similar approach, where I was trying to estimate the coefficients of a polynomial f(z) (1,2,3 degrees), over a dataset with planes, which corrected the depth. But then I stumbled upon a rather theoretical problem. Given a point (x,y,z) , changing its z coefficient should or should not change the remaining coefficients (x,y)?

I have the same problem with my D415 camera and it is driving me nuts.
A few thing I noticed:

Moving the camera horizontally or vertically doens't change the pattern
Changing the distance to plane changes the pattern a tiny bit
It's independent of whether the laser is on or off
Changing the (auto-)exposure or the gain doesn't change a thing

Based on these results and the locations of the "cirkles" I concluded that it might be caused by errors in the lenses. Maybe some sferical aberations might be the cause. There is a way to "correct" your data with a so called Fixed Pattern Noise Correction. Here is what you need to do:

Make sure your plane is as perpendicular to the z-axis as possible
Take around 50+ frames and take the average distance for every pixel over time, this will produce an average image
Devide every individual pixel value with the average of the entire image (this gives values around 0.8~1.2)
Store this data in a 1280x720 matrix (somewhere in text file for instance) or any format you can reconstruct

When you do a new measurement, you divide every pixel with the corresponding value in this calibration matrix. By doing so, you will remove the circular pattern.
Note: when the plane is tilted you will notice that this matrix no longer functions as expected. I haven't figured a way to fix this yet.

Thank you all for your responses and support. It is good to know that this phenomenon is something others observe as well, and has nothing to do with our particular setup or improper use of the RealSense camera.
In fact, we also tried a calibration-based approach, similar to what @TOMAxxHAWK mentioned. However, we require a solution that does not require a per-device calibration. We figured that the lookup-table-based approach works well for our use case per device, but is not applicable to multiple devices using a single calibration.

I think that the RealSense is too sensitive that will cause these things to occur. So small impurities will cause these artifacts to show up. So every camera will have it's own errors. Unless Intel develops a tool to completely remove these problems, we are stuck with these artifacts.
The main problem for me is that I am trying to determine what the ideal depth control settings are. But I am stuck because these artifacts really mess with my standard deviation of a plane. Because I want to measure a flat plane to get a feel for the accuracy of the camera without having to calibrate my data. I want my data to be as pure as possible, without having to filter or correct for certain artifacts.
Something I would like to add is that this type of camera is designed to measure complex structures. It is not optimised for flat surfaces. When I try certain object the structures beat the spatial noise of the camera. If you want to use this camera for absolute distance measurements, a Time of Flight method is better.

Hi @alexanderhaertl,
As previously mentioned, the D4 chip is not able to correct this residual distortion for the lens.
We do, however, hope the responses from agrunnet, vladsterz and TOMAxxHAWK have provided some guidance/helps for you to address this issue in your application.
Do you have any further question regarding to this problem?
Thank you.


chore: dropped pub fields from config module

Summary:
chore: dropped pub fields from config module
Issue Reference(s):
Fixes #2256
/claim #2256
Build & Testing:

[x] I ran cargo test successfully.
[x] I have run ./lint.sh --mode=fix to fix all linting issues raised by ./lint.sh --mode=check.

Checklist:

[ ] I have added relevant unit & integration tests.
[ ] I have updated the documentation accordingly.
[ ] I have performed a self-review of my code.
[ ] PR follows the naming convention of <type>(<optional scope>): <title>

Copy of the PR here — https://github.com/tailcallhq/tailcall/pull/2260/commits


Reaction to more atrributes and load data from cropAreaBounds

when any of these attributes changes, the canvas is rendered again.

try to fix #21

there is an annoying horizontal displacement of the crop area when loading pre set cropAreaBounds that I cannot get rid of =/
can someone help, me please?
should be

but instead I get

never mind, problem solved = )
ready to merge in.


DOCS-2895-compression-duke module docs

@juandesi Here's the rest of the compression module PRs from the old repo to the new.

This is just rolling in PRs from the old repo to the new:
https://github.com/mulesoft/mulesoft-docs/pull/3330


(Discussion) Create subpackages for the provider

@dmacvicar   @flavio  @monstermunchkin @inercia  is the terraform plugin design somehow preventing us to create golang subpackages?
What do you think about. I think this could help us to refactoring and organize code.
Maybe we if we agree, we should just focus on how and which packages we can create. :anchor:

I don't think anyone/anything can prevent you from creating golang subpackages. However, I had a look at some of the bigger providers in this project, and all of them are structured the same way without using subpackages.
We don't have that many files, so refactoring the code should be just fine. I don't believe that subpackages are a good solution here.

ok thx, closing


feat($injector): Deferred loading of providers into the injector

This is a draft for this feature. I'm still working on the API. Feedback welcome.
Summary
This is a proposal for a new API in Angular that would make it easier for developers to lazy load parts of their application.
This proposal is only for adding loaded providers into a bootstrapped app's injector. It does not include the lazy loading functionality itself, but rather complements module loaders like require.js, webpack, or SystemJS.
Motivations
Developers want to be able to lazy load application code for a variety of reasons. One is to deliver smaller initial payloads. Another is to hide application logic from unprivileged users (think admin panels) as a first layer of security.
Developers are already hacking their own lazy-loading solutions into 1.x, so there's a clear demand for support. Angular 2 will support lazy-loading, so having facilities in Angular 1 means we can write facades that better align APIs (for example, in the new router) and ease migration.
Finally, this API only addresses adding loaded code into Angular's injector, and does not implement lazy loading itself. There are already existing tools that can do this, so we just want to provide a nice API for them to hook into Angular.
Implementation
The implementation would consist of a new method on Angular Modules and a new service.
You would register some placeholder in the injector. Then you use a service to add the provider later.
lazy.js:
var lazyModule = angular.module('lazy', []);
lazyModule.factory('a', …);

app.js:
var ngModule = angular.module('app', []);

// names of services that some module will provide
ngModule.placeholder(['a', 'b', 'c']);
ngModule.directivePlaceholder(['myFirstDirective', 'mySecondDirective']);

ngModule.run(function($lazyProvide) {
  $lazyProvide.addModule('lazy'); // or: $lazyProvide.addModule(lazyModuleRef);
});

The only change to the behavior of the injector is that trying to inject a service that only has a placeholder, and not a corresponding provider implementation will throw a new type of error. The injector is still synchronous. HTML that has already been compiled, will not be affected by newly loaded directives.
Placeholders
The goal of this placeholder API is to make it easy to reason about how an app should be put together. Still, it's important that the ability to lazy-load parts of your app isn't prohibitively expensive because the work of adding the placeholders is too much.
The placeholder API is designed so that if a developer is using the AngularJS module system in an idiomatic way, you could statically analyze an app and automatically generate placeholders. ng-annotate already has most of this functionality, so I suspect it'd be easy to add generating placeholders to it.
Okay but I really hate the placeholders thing
You can disable the requirement to have a placeholder before a module is lazily added with the following directive:
<div ng-app="2Cool4SchoolApp" ng-allow-dangerous-lazy-providers>
  <!-- ... -->
</div>

This works the same as ngStrictDi.
If manually bootstrapping, you can use the following bootstrap option:
angular.bootstrap(someElt, ['2Cool4SchoolApp'], {
  allowDangerousLazyProviders: true
});

This is for developers who really know what they're doing, and are willing to maintain the invariants about lazy loading manually.
My goal is to make it so easy to provide placeholders that we can deprecate this API because it's never used. But because there's a clear demand for such an option in the Angular community, I want to make sure that it's possible.
Module redefinition
To avoid situations where it's ambiguous which implementation of a module is used in an app, once an app has been bootstrapped, any modules that include a placeholder cannot be redefined. Trying to redefine a module like this will throw an error:
it('should throw if a module with placeholders is redefined after being bootstrapped', function () {
  angular.module('lazy', []).placeholder(['a', 'b', 'c']);
  angular.bootstrap(document, ['lazy']);
  expect(function () {
    angular.module('lazy', []).placeholder(['d', 'e', 'f']);
  }).toThrow();
});

it('should not throw if a module with placeholders is redefined before being bootstrapped', function () {
  angular.module('lazy', []).placeholder(['a', 'b', 'c']);
  expect(function () {
    angular.module('lazy', []).placeholder(['d', 'e', 'f']);
  }).not.toThrow();
  angular.bootstrap(document, ['lazy']);
  // expect the bootstrapped app to have placeholders for `d`, `e`, `f`.
});

Adding to a module after bootstrap
To avoid situations where it's ambiguous what is actually included in a module, once a module with placeholders has been included in a bootstrapped app, it cannot have new placeholders or providers added to it.
it('should throw if a module has placeholders added after being bootstrapped', function () {
  angular.module('lazy', []).placeholder(['a', 'b', 'c']);
  angular.bootstrap(document, ['lazy']);
  expect(function () {
    angular.module('lazy').placeholder(['d', 'e', 'f']);
  }).toThrow();
  expect(function () {
    angular.module('lazy').factory('foo', function () {});
  }).toThrow();
});

it('should not throw if a module has placeholders added before being bootstrapped', function () {
  angular.module('lazy', []).placeholder(['a', 'b', 'c']);
  expect(function () {
    angular.module('lazy').placeholder(['d', 'e', 'f']);
  }).not.toThrow();
  angular.bootstrap(document, ['lazy']);
  // expect the bootstrapped app to have placeholders for `a`, `b`, `c`, `d`, `e`, and `f`.
});

Loading new code
Loading the provider implementation would be left up to the application developer. It is the responsibility of the developer to make sure that components are loaded at the right time.
For instance, you might use it with ngRoute's resolve:
$routeConfig.when('/', {
  controller: 'MyController',
  resolve: {
    'a': () => $http.get('./lazy.js').then((contents) => {
        // this example is silly
        $injector.addModule(eval(contents));
        return $injector.get('a');
      })
    }
  });

This API intentionally does not include a way to "unload" a service or directive.
Run and config blocks
Lazy loaded modules will not run config blocks:
it('should throw if a module has config blocks', function () {
  angular.module('lazy', []).config(function () {});
  expect(function () {
    $injector.addModule('lazy');
  }).toThrow();
});

But lazily loaded modules will run run blocks when they are loaded.
it('should run run blocks', function () {
  var spy = jasmine.createSpy();
  angular.module('lazy', []).run(spy);
  $injector.addModule('lazy');
  // flush
  expect(spy).toHaveBeenCalled();
});

Risks
The API should mitigate the possibility of making it difficult about the state of the injector. For example, we want developers to be able to distinguish between a case where a user mistyped a provider's name from a case when it was requested before it was loaded. Since compiled templates will not be affected by lazily loaded directives, the compiler should also warn if it compiles a template with placeholder directives, but not their implementation.
On the other hand, the "placeholders" should not require too much upkeep, otherwise this API would be too cumbersome to use. Ideally, the placeholders could be automatically generated at build time.
Prior art
I looked at these lazy-loading solutions:

overmind – https://github.com/geddski/overmind
webpack bundler – https://github.com/webpack/webpack
ocLazyLoad – https://github.com/ocombe/ocLazyLoad
angular-widget – https://github.com/wix/angular-widget

So just to be clear: this solution explicitly does not support unloading of components, right?
Also, although it allows directives to be lazily loaded, HTML that has already been compiled, will not then receive the benefit of the newly loaded directives, right?
Finally, what is the motivation for using a new service $lazyProvide, rather than, say, adding a new method to the $injector? The latter would seem more intuitive to me.

So just to be clear: this solution explicitly does not support unloading of components, right?

yes – amended my original post

Also, although it allows directives to be lazily loaded, HTML that has already been compiled, will not then receive the benefit of the newly loaded directives, right?

yes – amended my original post

Finally, what is the motivation for using a new service $lazyProvide, rather than, say, adding a new method to the $injector? The latter would seem more intuitive to me.

Agreed. That seems better.

Wooo this is awesome (sad for my lib) but awesome for angular !
I like the placeholder idea, and also the new injector function, you should add both.
Also, any chance that we could add an interceptor to the loading of a placeholder ?
Here is the scenario: you access a controller that requires a service, angular will try to inject the service, this service hasn't been loaded yet and the interceptor (I say interceptor, but it might be something that you define in the config of your main module) will load the new file and return a promise to the controller which will not be instantiated until the promise is resolved. This would work the same way as the resolve method in the router.

This looks very promising. There are a few things that I find not clear, probably the most problematic is how will this work when there is a module redefinition. Eg.
var moduleA = angular.module('lazy', []);
moduleA.placeholder(['a', 'b', 'c']);
moduleA.run(function($lazyProvide) {
  [...]
});

var moduleX = angular.module('foo', ['lazy]);

[...]

var anotherModuleA = angular.module('lazy', []);
moduleA.placeholder(['d', 'e', 'f']);
moduleA.run(function($lazyProvide) {
  [...]
});

var moduleY = angular.module('bar', ['lazy]);

In this case, there are two apps, the app foo and the app bar. The former uses one definition of a module named lazy and the later another. How should the implementation of each of those lazy look like? The reason being that it cannot be
var lazyModule = angular.module('lazy');
lazyModule.service(...);

as if this is done after the module redefinition, then it will add these service to the new version of lazy.
A second question is the following (in this scenario there are no modules redefinitions at all): If there is a lazy module, and this lazy module is used in two different apps. If the first of the apps does whatever needed happen and the implementation is loaded. Will this also load the definition for the second app?

@lgalfaso  - this is not how I understand it working.  You specify in your loaded* module placeholders that will be provided by some lazy loaded module later.
 The actual implementation of these services can be loaded via any kind of module at a later time:

app foo's $injector contains placeholders for a, b, c
app bar's $injector contains placeholders for a, b, c, d, e, f

We don't reopen modules to load the lazy components. We actually create a completely new module and load it into the injector - it just happens to fill some or all of these placeholders.

Right now, when the line var anotherModuleA = angular.module('lazy', []); is executed, then a new module named lazy is created, but foo is still hooked to the old lazy. When bar is created, then it is hooked to the new lazy. Will this change?

I'm not sure I understand the purpose of having to define placeholders for the lazy loaded module. Is this only so that users get a more descriptive exception if they try to use those services prematurely? What happens to service that are defined in the lazy loaded and were not defined as placeholders? Won't they get added to the injector as well when the lazy module is loaded into the injector?

I don't see it being a good idea.
If you look at the definition of Lazy Loading, you will see it comes from languages (C, C++, C#) that support the concept of interfaces, which gives the ability to intercept invalid calls, i.e. calls on instances not yet loaded, so they can be loaded on demand. JavaScript cannot intercept invalid calls, so unless you provide a coding around for every single call attempt, things won't work. And throwing an exception as a standard approach isn't a good idea. Your Achilles heel is right there.
The only lazy loading that JavaScript can do is loading up pieces of code in accordance with the UI partitioning as dictated by the business/dependency logic. For this you've got: Browserify and Webpack. I sincerely hope you are not suggesting to implement one of those as part of Angular core, it would be a shot in the head. A separate module though might make more sense, but the existing alternatives are already too good to just pass them by. There are only so many things Angular can absorb before imploding.
Links:
http://webpack.github.io/
http://esa-matti.suuronen.org/blog/2013/04/15/asynchronous-module-loading-with-browserify/
http://en.wikipedia.org/wiki/Lazy_loading

@VitalyTomilov – not sure if you read the proposal, but it's for an API to be used alongside a module loader, not a module loader itself. The idea is to complement something like webpack or require.js. Your points seem targeted at the "virtual proxy" style of lazy loading, which is totally unrelated to the implementation being proposed.
I added a bit more to the summary to make this more explicit.

@shahata – great questions.

I'm not sure I understand the purpose of having to define placeholders for the lazy loaded module. Is this only so that users get a more descriptive exception if they try to use those services prematurely?

Yes. This is something @IgorMinar suggested.

What happens to service that are defined in the lazy loaded and were not defined as placeholders? Won't they get added to the injector as well when the lazy module is loaded into the injector?

Let's say you load module 'lazy' with some service foo for which a placeholder was not provided. If you attempt to lazily add a provider for foo, the injector will throw an error, explaining that it did not expect foo.
I'm trying to think how to clarify my original post with these answers. Suggestions welcome!

I think this "strict" behavior of throwing if a provider without a placeholder is added lazily should be optional (maybe even opt-in). It sounds like a place where people will keep banging their head when they add some service in the lazy loaded module and forget to add a placeholder....

Also, any chance that we could add an interceptor to the loading of a placeholder ?
Here is the scenario: you access a controller that requires a service, angular will try to inject the service, this service hasn't been loaded yet and the interceptor (I say interceptor, but it might be something that you define in the config of your main module) will load the new file and return a promise to the controller which will not be instantiated until the promise is resolved. This would work the same way as the resolve method in the router.

@ocombe – this is something I already considered, but it would mean totally rewriting the injector (and anything that uses it) to be totally asynchronous. This means rewriting the compiler, and anything that relies on it. In short, it's entirely too much work and would be a huge breaking change. The good news is that Angular 2 will support Async DI out-of-the-box, so you'll be able to do something like what you propose.
I think the proposed API makes it easy to lazy-load on route changes, which seem to be the 90% case. And it does so without a sweeping breaking change.

So glad this is on the radar! Thanks @btford. I agree with @shahata though on the placeholders. If you have to define a placeholder for every service, directive, filter, controller etc to be lazy loaded that would be an enormous amount of extra work for the developer. It's also redundant information that now lives outside of your lazy-load boundaries, reducing the benefit of separation/lazy loading in the first place. Could the placeholders with their associated error messages be optional?

The idea of placeholders is not so painful if you think of it in terms of "module interfaces". the idea is that for any module that you wish to lazy load, you provide an empty shell module that only specifies the placeholders.
For example we could load these three modules at our normal application startup:
angular.module('myApp', ['lazy1Interface', lazy2Interface']);

angular.module('lazy1Interface', []).placeholder(['a', 'b', 'c');
angular.module('lazy2Interface', []).placeholder(['d', 'e', 'f');

Then later we could lazily load modules containing the real implementation of those services:
var lazy1 = angular.module('lazy1', [])
  .factory('a', function() { ... })
  .factory('b', function() { ... })
  .factory('c', function() { ... });

$injector.lazyLoad(lazy1);

var lazy2 = angular.module('lazy2', [])
  .factory('d', function() { ... })
  .factory('e', function() { ... })
  .factory('f', function() { ... });

$injector.lazyLoad(lazy2);

One could even generate these lazy interface modules automatically from you concrete modules if you wanted via a build tool.

If you have to define a placeholder for every service, directive, filter, controller etc to be lazy loaded that would be an enormous amount of extra work for the developer.

Agree that this is tedious by hand, but I think this it's solvable with tooling.

It's also redundant information that now lives outside of your lazy-load boundaries, reducing the benefit of separation/lazy loading in the first place.

The information isn't exactly redundant, but it's true that this info is only useful during development.

Could the placeholders with their associated error messages be optional?

I'm worried if we go this route, developers will at first not find the feature valuable, only to later discover that they want it when their app is complex. It's the same trap some developers fell into with DI and minification.

@petebacondarwin @btford the thing is that the services defined by some module are not by any way its public interface. A module might have many services which it uses only internally and not any business of anyone who wants to load it lazily. More over, imagine I set up some lazy load for some module and everything works fine - a new version of that module which was refactored to extract some internal service could completely break my app...

Another thing (unrelated to the current discussion) - the description above talks a lot about lazy loading providers, but actually we cannot lazy load providers (as in angular.module('myApp').provider(function () {});), right? (since the "config" phase is already over by now)

Yeah that might be a problem, you might not know the full extent of the services/directives/... of a module. You might just use one service, but if you need to predefine them all then you will have to read the source code for that.
Why do we need to define placeholders like that in the first place? Couldn't you just allow the definition of any angular component at any time? If you lazy load a new module it will define its own services & directives at the same time and you should execute the associated invokeQueue & configBlocks when they are defined (if the app has already been bootstrapped).
I get that you might want to know that a service is a placeholder when you try to instantiate it. Maybe we could have a specific syntax for that like ::$service instead of $service ? Or maybe we could just define the place holder for the services we need in our not-lazy-loaded component, but if a new lazy loaded module has more services than you defined then they might still work (because they are defined at the same time of the module?).

My concern
The instructions of what to load (url), and how to load them (procedure) is located where you request the module, rather than where you declare your module placeholder. This means that if you need the same thing in several places you have to maintain the instructions in all of those places. This means two things:

We have to add instructions to the consumers, which isn't very DRY, and moving files around means you need to update all of those urls (which is allready annoying for templateUrls).

If you start without lazy-loading and want to turn it on later, you have to modify your code by adding instructions.

Let's deal with them one at a time.
Counter proposal 1
To deal with the first issue I propose that we add a new declaration syntax which, in addition to the names of the injectable symbols and directives, includes the url or loading-function of the module:
// Same base for both approaches
var mod = angular.module('mymod', ['dep1','dep2'])
mod.lazySymbols(['a', 'b', 'c'])
mod.lazyDirectives(['dir1', 'dir2'])

// By url
mod.lazyUrl('./mymod.js');

// By loader function
mod.lazyLoader(myLoader, ['stuffArgs']);

function myLoader(stuff) {
  return "the code stuff";
}

In effect this simply moves the instructions of how and what to load from the consumer to the declaration. Also I made some changes to naming which I like. This way each lazy-loading method starts with "lazy" so that it's obvious that they belong together. (What's the common term for services, values, factories etc? Would lazyInjectables() be better than lazySymbols()?)
The result is that tooling can now rewrite urls for us automatically without messing with our source code, allowing us to move things around without worrying. Furthermore this is much cleaner as regards separation of concerns; the consumer really shouldn't care where the module comes from, just that it needs that module.
If you keep this proposal, but discard my counter proposal part two then we will still need code at the consumer asking for a lazyloaded module. However it is now much simpler than in the original proposal. Where the consumer used to say "I need that module to be loaded from that location in this way" it is now simply saying "I need that module to be loaded", which I think is a pretty big improvement. Here's what it will look like:
$routeConfig.when('/', {
  controller: function(a){},
  resolve: {
    '__lazy': () => $injector.lazy('mymod')
    }
  });

Where $injector.lazy() returns a promise which resolves once the module has been loaded and the placeholders replaced. Once that's done calling $injector.get('a') should work as normal, and the controller and compiler should get what they expect.
Notes

Doing an $injector.lazy('mymod') should also load any downstream modules it depends on that are also lazy declared.
It should be permissible to provide the same lazyUrl(..) for several modules and have them all defined in the same file.
Those two mean you usually shouldn't have to load many modules. But if you do, you can use $q.all or add several resolve properties.

Counter proposal 2
In order to deal with issue 2, we have to go a step further. If the $injector is going to be able to lazy load lazy-declared modules seamlessly it would need to be based on promisses. By changing the $injector so that $injector.get() would return a promisse it could use a preloaded or lazyloaded module interchangeably.
I am unsure how much work would be involved, but my gut feeling is that it isn't trivial. I mean, that last snippet with the one-liner resolve didn't look that bad, so I'm inclined to say that it might not be worth it. But I think it's at least worth discussing.
The result

We wouldn't need a resolve block at all.

It would be a breaking change for anybody calling $injector.get(). However I find it probable that mostly people call it to get around the limitations we are discussing, and possibly for some manual bootstrapping, which should be fairly easy to migrate.

By removing the need for an $injector.lazy() method, it would be much easier to use lazy-loading of modules for any part of a system. Without it there will always be a need for a structured choice of when and architecturally where to load. In an application using a router the choice is obvious and outlined above. But not all applications uses a router.

@gautelo - thank you for you input. I think that this issue thread has brought up some really useful points and discussion.
We have talked about making the injector async in the past but I think that this would be too much of a change for Angular 1.x. As you said, putting the load into a resolve is enough to work around this problem and itself is fairly explicit and intuitive.
Regarding, moving lazy load declaration information to the module, I really like that idea. I wonder if one could go a step further and separate the loader from the module too? Then you would have a situation where the user of the lazy loaded code would not need to know about where and how it was loaded, but also the creator of the module would not need to know what loader was to be used to load it.  Does that make sense? An implementation I am thinking about would be to define the loader(s) separately with some mapping between lazy module (url?) and loader.

@petebacondarwin It's funny you should mention that. I actually had a code example like this, but decided to remove it to get my point across as simply as possible.
Simply put the lazyLoader function parameter could be set globally, and then you would simply specify the arguments instead of both the loader and the argument.
// At, or before, bootstrapping
angular.setLazyLoader(myLoader);

// At module definition time
mod.lazyArgs(['stuffArgs']); // There are probably better names.

// If you don't set a custom loader this will be synonymous with
mod.lazyUrl('stuffArgs');

The problem is that this doesn't take us all the way as the content of the lazyArgs depend on the loader function, so I don't see how we can proceed to get a clean separation. We need to describe how/where to load along with the placeholders in some way shape or form.

@gautelo – totally agree with your first counter proposal. You should be able to add some metadata about how to load the module to where you declare the placeholders.
Your second counter-proposal would not work. See https://github.com/angular/angular.js/issues/11015#issuecomment-73628247
I'll try and spend some time this evening updating my proposal accordingly.

@btford Awesome. Looking forward to this. :)

All the async injector proposals I've seen suggest changing currently synchronous injector methods to be async. But have we considered just adding async versions of those methods or adding an $asyncInjector service? Seems like that would resolve the BC issue, no?
The async injector could just take promises registered by the normal injector and resolve them before injecting. Or it could have a totally different registry of services and only fall back to the sync injector if none is found. I.e. the sync injector is a child of the async.
The compiler would use the sync router still so it doesn't have to be rewritten, but the router could use the async injector.

The async injector could just take promises registered by the normal injector and resolve them before injecting. Or it could have a totally different registry of services and only fall back to the sync injector if none is found. I.e. the sync injector is a child of the async.

This introduces a ton of incidental complexity, and also severely limits the usefulness of being able to lazy-load code at all. For instance, with this approach, you cannot lazy-load anything that core APIs would inject. This means directives, controllers instantiated with $controller, filters, etc.

To address @lgalfaso's comments, I've added two sections – "Module redefinition" and "Adding to a module after bootstrap." tl;dr, I think we should just throw in situations where someone tries to mess with a module that has placeholders after that module has been used in a bootstrapped app. I can't think of any great cases to allow someone to add more placeholders later. In fact, that would totally defeat their purpose.

Would this proposal allow me to build a plugin system, where the application at build time knows the interface of a plugin but does not know which or how many plugins will be available at runtime to satisfy the interface? That’s what I’m currently trying to use lazy loading for, and it seems like the requirement for placeholders makes that impossible. If every plugin (for a specific interface) provides injectables under its own names, then the application needs to know about all plugins to declare their placeholders. If the placeholders just define the interface and all plugins provide injectables of the same names, then I can only have one plugin loaded into the application at a time. Both defeat the purpose of a plugin system. Am I understanding this correctly?

@cwalther I don't think this proposal will help you if your requirement for your plugin system is to be able to have more than one implementation of one module interface. For that to work you would have to describe the implementation with some kind of keyword, and provide that when you load. How would the module loader know which implementation to return otherwise?
There is no such functionality in this proposal (or in angular, for that matter.) It is meant simply to allow you to define things up front and load the (single) implementation on demand.

@btford I have a few questions that popped into my head, let me summarize what I understood of the proposed implementation:
When you want to do some lazy loading, you can add modules as placeholders (those modules will be lazy loaded later), and also components (that will probably come with those lazy loaded modules).
Then later when you need a component that has been defined as a placeholder, it will have to have been lazy loaded before you need it because angular will invoke it synchronously.
The lazy loading part will be left to the developer (using requirejs or any kind of existing loader).
Questions:

With this implementation, when we lazy load a module, do we have to define all of its components as placeholders, or just the ones that we need ? For example if you load module A that has 3 services ($a, $b & $c), but that you only need $a, do you have to define placeholders for the 3 services? Or just the one that you will use?

What happens when this lazy loaded module uses more other modules internally? Do we have to define placeholders for all of them, or can we ignore them since the lazy loaded module will define them? For example you lazy load module A, that internally is defined as a module that requires modules A.a & A.b (that are both defined in the same file)

Can you define placeholders for components without having placeholders for modules? Let's say that you just want to lazy load a service for your main module, is this possible? Or do you have to create a new module for each lazy loaded part?

If you define a placeholder for a directive and that you use an html element that would have triggered this directive, would this throw an error? Let's say that you define a directive for the tag "input", if you have an input into your dom and that you have defined a placeholder for "input", what will happen? If there is no error thrown, will those tags be automatically recompiled when you lazy load the directive, or do you have to do that all by yourself?

How can you define multiple placeholders for directives with the same name? Angular allows us to define multiple directives with the same name, so it should theoretically be possible to have 2 directives with the same name in the same module (bad, bad practice), how will you handle that?

I'm wondering if this is not introducing security risks?
Currently when an Angular application has been bootstrapped, it can't be altered, so it can't be tampered with.
However, suppose that lazy loading is introduced and suppose that you create a placeholder for a service that needs to be lazy loaded.
Wouldn't this provide a visitor with the ability to inject a harmful service into the Angular application using the console in the browser before the service has ever been lazy loaded?

It wouldn't change anything, javascript isn't secure anyway, it's client side and you can do what ever you want with it, even with the current angular applications.

@jvandemo That can be done without lazy loading as well. I don't consider a web client a secure client. It is always possible for a user to inject/intercept things. Even if they for some reason don't realize how to pause angular when it's about to bootstrap, you can always modify things. It's javascript. It's not meant to be locked down. Your server is supposed to be the thing that's locked down.

Wouldn't this provide a visitor with the ability to inject a harmful service into the Angular application using the console in the browser before the service has ever been lazy loaded?

@jvandemo  – If an attacker can run arbitrary JS on a page, you're doomed regardless of whether you're even using Angular. What's to stop an attacker from tearing down the existing app and bootstrapping a new one with malicious code?

Would this proposal allow me to build a plugin system, where the application at build time knows the interface of a plugin but does not know which or how many plugins will be available at runtime to satisfy the interface?

@cwalther – If I understand correctly, I think this use case is completely at odds with what we're trying to do with placeholders, and isn't really common enough to warrant in core. The good news is that there are other ways to accomplish this sort of behavior, albeit not at the DI level. Also this is a case that Angular 2's DI system can handle elegantly.

@btford I heard mention of this feature a few times at ng-conf, so I went back to check what's happening. You mentioned that you would try to incorporate my "Counter proposal 1" into your proposal. However I don't see it in the "Loading new code" section where I would expect it. Didn't it make the cut after all? Awaiting further clarifications, or is this issue abandoned and a solution allready in place somewhere else?

@gautelo – Sorry, I'm still in the process of incorporating all the feedback. It was my intention to add your suggestions to the proposal. I'll try and update the original post today.

@ocombe –

Do we have to define all of its components as placeholders, or just the ones that we need ? For example if you load module A that has 3 services ($a, $b & $c), but that you only need $a, do you have to define placeholders for the 3 services? Or just the one that you will use?

If you try to register$b with the injector and it has no placeholder for $b, it will throw, even if $b is never instantiated. So the answer is you should either move $b into a different module and not load that module (better), or add a placeholder for it.

What happens when this lazy loaded module uses other new modules internally? Do we have to define placeholders for all of them, or can we ignore them since the lazy loaded module will define them? For example you lazy load module A, that internally is defined as a module that requires modules A.a & A.b (that are both defined in the same file)

You'd need placeholders for the transitive graph of dependencies. I don't think it's possible to implement otherwise.

Can you define placeholders for components without having placeholders for modules? Let's say that you just want to lazy load a service for your main module, is this possible? Or do you have to create a new module for each lazy loaded part?

I don't understand what this means. A module is just a "bucket" that holds providers, run blocks, config blocks, and placeholders.

 Without needing the define a new module each time

You can only inject an entire module. Modules are the level of granularity for lazy loading. If you want to load part of a module, you'll have to split the module into parts as needed.

If you define a placeholder for a directive and that you use an html element that would have triggered this directive, would this throw an error?

Yes. Well, maybe not an error, but you'd at least get a warning.

Let's say that you define a directive for the tag "input", if you have an input into your dom and that you have defined a placeholder for "input", what will happen? If there is no error thrown, will those tags be automatically recompiled when you lazy load the directive, or do you have to do that all by yourself?

There will definitely not be any recompilation for directives.

How can you define multiple placeholders for directives with the same name? Angular allows us to define multiple directives with the same name, so it should theoretically be possible to have 2 directives with the same name in the same module (bad, bad practice), how will you handle that?

There will need to be support for having multiple placeholders of the same name for directives.

  And actually, you only lazily provide, something else (a code loader) actually does the loading. If you try to add something to an injector, it will throw when you try to add it with this new API.

Also this is a case that Angular 2's DI system can handle elegantly.

I’m glad to hear that!
Thanks for the confirmation about placeholders and plugins, that’s what I suspected. I’m not so much worried about 1.x actually, as what I’m currently doing there (which, if I understand correctly, is what other current lazy-loading solutions do: keeping the registration methods of a module around during the run phase) seems to be working well enough so far.

Hmm ok thanks for the answers @btford. That's what I feared: this implementation will be really hard to use. If you want to lazy load a module from an external library you'll have to create placeholders for all of their services, controllers, ... It will be a nightmare.
Let's say that you want to lazy load angular-translate, I have no idea what the name of 3/4 of their services/directives/... are, and they probably define many things for internal use, when I only use one or two services. How do you expect users to know about all of those things? They will have to read the source code of every new library that they want to lazy load?
There should be a way for users to only define placeholders for the things that they'll use. If you say that we can only lazy load modules, then this should be easy to implement. The hard part with lazy loading is when you want to add new components to existing modules because you have to think about the run/config phases, about the existing components with the same name, ... But loading a complete new module should not cause too many problems. In fact lazy loading new modules doesn't really require placeholders.
I'm afraid that if you choose this implementation then you will complicate the process more than necessary. But it is also good news for me because it means that ocLazyLoad will still be useful :)

@ocombe You've missed the main thing. You shouldn't manually write these placeholders. That should be automated by your build process. It shouldn't be very hard to extract this information from your (or other peoples) sourcefiles and dynamically build the placeholder files from grunt/gulp.
The second most important thing that's missunderstood is which things should be lazy loaded.  If your application consists of hundreds of views and an inhouse component library with data services etc., then you should lazy load your view modules, not your component and service library. In short, this is not an effort to lazy-load framework. It's an effort to lazy load application parts for those applications that are huge.
 Those are probably used by everything anyway, so they would be loaded in the start no matter what.
(Of course there might be an instance where one subset of your components/services are used exclusively for certain views. Well, in that case make those things a module, and generate the placeholders. This proposal should still help in that case.)

this implementation will be really hard to use

I think @geddski had similar concerns. I'm exploring an approach that would make it easy to automatically generate the placeholders. The problem is that it's very difficult to statically analyze the Angular module API. It might be worthwhile to also provide an option to turn off this strict "placeholder." requirement, with the understanding that in doing so you might create a system that's difficult to reason about.

I'm afraid that if you choose this implementation then you will complicate the process more than necessary. But it is also good news for me because it means that ocLazyLoad will still be useful :)

ocLazyLoad will be useful regardless – this API is just one piece in lazy loading, not an end-to-end solution. :)

@gautelo: Hmm yes I took angular-translate as an example, but it's probably something that would be used everywhere in your app.
Let's say that I want to lazy load ui-grid because I have grids somewhere in the app. I don't need this in other parts of my app.
 It's really rare that your own modules become so big that you need to lazy load them to gain enough kb to make it worth while.
Of course you can use tools for that, but someone will have to write them before you can use them (In fact, I started working on something similar for ocLazyLoad, so maybe it will be useful for Angular in the end, not just for my lib).
But those tools will probably have bugs, or maybe they won't be maintained as fast as you'd like (if someone does it on his free time like most open source projects, you can't expect them to add new code every days).
And many developers don't use tools (I know, it's a shame but it's also a fact). Tools are for dedicated developers. Also sometimes you just want to write a quick PoC and don't want to take too long on adding/configuring tools.
@btford: I'm really interested in this approach that woul help generating the placeholders. I started working on a code analysis tool that would understand Angular dependencies, but if you have any leads, please share them :)
If we can turn this "strict mode" off, then it would make it way easier. Only those who know what they do and accept the risks will turn it off and everyone is winning.

@ocombe I agree, for a quick poc I won't use tools. And also I won't bother with lazy-loading ;)
As for a non-strict mode. I do appreciate that this could be very usefull for many. Definitely worth exploring if it's possible to support something like that.

@jvandemo – If an attacker can run arbitrary JS on a page, you're doomed regardless of whether you're even using Angular. What's to stop an attacker from tearing down the existing app and bootstrapping a new one with malicious code?

@btford — You're right, I never thought of tearing down the entire app and bootstrapping a new one. I always thought you were safe after the bootstrap process in that you couldn't inject malware anymore. Thanks for explaining! (Thanks to @gautelo @ocombe as well!)

just a +1 for making the strict mode optional for all the reasons mentioned above
an extra +1 to make it opt-in
and a stretch +1 to make it opt-in per module

@btford my mind is puzzled with this:
I assume .config() and .run() of lazy loaded modules to be executed as JS is loaded, whatever means are used to load it.
This means the execution order (config > run) will be vertical (as in per module) as opposed to horizontal (all configs > all runs).
Isn't this a problem for loading groups of modules with complex inter-dependencies that are phase sensitive?

@andrezero Yes, that's a problem. I see only two solutions, and neither one is optimal.

 (Potentially confusing.)
Disallow lazyloading modules with .config() and/or .run() blocks. (Less confusing, but is limiting the usefullness. However, the main scenario involves the router. The run-block for the ui-router is effectively the resolve blocks. So not being able to have config/run blocks shouldn't really be a problem in the main scenario.)

Would it make sense to make placeholder definition a little more intuitive using a pre-defined constant in the global angular object?
Example:
module.directive('directiveName', angular.TO_BE_LAZY_LOADED);
module.service('serviceName', angular.TO_BE_LAZY_LOADED);
module.filter('filterName', angular.TO_BE_LAZY_LOADED);

This could prevent the need for placeholder* functions and if angular.TO_BE_LAZY_LOADED is an object, it could be very quick to detect equality using === in scripts that need to detect whether something has already been loaded or not.

To lazy load something, you could then check to see if your required component (service, filter, etc) is an instanceof(angular.TO_BE_LAZY_LOADED) and if so, you would immediately have the definition object that contains all info to actually load it (or pass to your custom loader that does the actual loading).
Once the loaders has finished, the definition object would be replaced by the lazy loaded object.
Don't know it that would make sense though?

@gautelo @btford regarding the config/run order of lazy loaded modules, not allowing at all it is severely limiting ... means you could not lazy load any part of your app that contained config/run block .. so many libraries out there do have them, even if sometimes not for the right reasons.
What if there is a simple method to "apply" the lazy loaded modules, i.e., to tell angular that new modules were loaded and they need to have their config/run blocks invoked "horizontally"?
Consider modules lazyA and lazyB loaded by some means after the app is running, invoking something like angular.loadedModules(['lazyA', 'lazyB']) would trigger existing config() blocks followed by run() blocks.
The tradeoff is that the lazy loading mechanism needs to be aware of which modules are being loaded, and skipping one of them can probably yield weird results (or crashes) that are hard to trace.
But still, worthy to test the theory, since I can't find any other way that does not involve "nuke" options like the ones mentioned by @gautelo.
Say we are navigating to our "admin" section and we want to load it and suppose we have it bundled in a single file.
resolve: {
  'foo': function () {
    lazyLoaded.load('./admin.js').then(function () {
      angular.loadedModules('admin', 'dashboard', 'fancyGrid', 'fancyCharts');
    });
  }
}

These thoughts have been in my head for more than one year, I'm glad there is finally a proper place to share them, but I also don't have solutions. So, just my two convoluted cents.
Cheers

The config/run blocks on new modules should be executed when they are lazy loaded, and the ones from the dependencies should not, by default.
What I did in ocLazyLoad is add params that you can use to rerun config/run blocks on dependencies, but you have to explicitly use this param, because it can often lead to errors or strange behaviors.
There aren't a lot of cases where this is needed, and just executing the run/config block on the new lazy loaded modules is usually what you want.

I agree, it's probably a mistake to disallow lazy-loading modules that include config/run blocks. The consequence is that you get things run out of canonical order, or horizontally, as you say. But as long as things are fairly independent that shouldn't cause any issue 90% of the time. Having the option to rerun blocks, as @ocombe mentions, might solve another 9%. No idea what the last percent is, but it's bound to be something or other.. :)

config blocks can change a behavior and must be executed before the app starts. The immediate consequence is that whatever needs to be configured cannot be loaded after an app starts, and config blocks added to a module after an app should not be executed (BTW, this last part is true for lazy-loaded modules or not, and also applies today)

I think it's okay to run run blocks, but it's really a bad idea to try to run config blocks. I think by default, it should throw if you try to add a module with config blocks, maybe with an option to ignore them.

Would it make sense for a build tool to extract config blocks from dependencies together with the items that are needed to execute them (e.g. the providers) during initial bootstrap?

May be prone to errors though as it would probably get complicated...

I will not oppose that when adding a run block, then running applications should execute it, but this is not how applications work today... Anyhow, I think this can cause confusion

One idea would be to allow config blocks, but only when all injected providers are from the module or module-tree that's being lazy-loaded. Basically that we only block the config blocks if you attempt to lazy load a config block that takes an already loaded provider. But again, that could add confusion.

@geddski @ocombe – I just added a new section called "Okay but I really hate the placeholders thing"
Let me know what you think.

Hey, works for me :)
Thanks

Yay thx @btford!

Hi,
Currently at work we are implementing a very very modular angular app using lazy loading, the basic idea is to be able to create a sort of Angular RCP (a la eclipse) and create plugins instead of apps.
Every plugin is implemented as an angular module.
This means we have only one angular app but it's functionality is completely dynamic depending on the plugins/components/modules you want to load. For example, we have a main menu directive with a provider that allow us to add new items to the menu, so if we want to expose a new functionality in the app we only need to create a new plugin, hook into the main menu provider  and voilá the app is extended.
Every plugin defines its dependencies that are lazy loaded (the plugins itself are also lazy loaded) into the angular app by using the great oclazyLoad library and requirejs.
The initial list of plugins to load comes from a backend service.
This gives us a great amount of flexibility we can expand/modify the app's functionality without code changes, great for role based authorization for example. And allow us to work on reusable isolated components instead of apps. Also we have only one deployed app which can give service to a lot of different user needs based on the components to load
I told all this because I believe this is a use of lazy loading you guys have not considered, all this proposal seems to be based on the idea of lazy loading components that are previously known, for performance reasons, reduce footprint, etc. But what about if I want to lazy load some modules dynamically, that is modules not known at coding time?
Some friction points:

Placeholder thing: The ng-allow-dangerous-lazy-providers directive seems a must, I would  have nothing against placeholders if I could define them after app bootstrap (which I believe is not possible in the current proposal).
Config and run blocks: This is another problem, it could be very interesting for a lazy loaded module to be able to add functionality to the app using standard angular ways. One of this ways I believe is providers. If config or run blocks are not allowed then somehow lazy modules are not regular angular code but a sort of "second class citizens" in an angular app which would IMHO seriously limit its usefulness or capability to be reused as usual angular components or libraries.

HTH, Raúl

But what about if I want to lazy load some modules dynamically, that is modules not known at coding time?

I'm working on an internal application that defines all the uI (custom directives and basic layout) and security modules with their dependencies. Other applications (modules) will be loaded with any dependencies needed based on department/roles and are not referenced until authenticated.

Config and run blocks: This is another problem, it could be very interesting for a lazy loaded module to be able to add functionality to the app using standard angular ways. One of this ways I believe is providers. If config or run blocks are not allowed then somehow lazy modules are not regular angular code but a sort of "second class citizens" in an angular app which would IMHO seriously limit its usefulness or capability to be reused as usual angular components or libraries.

Run lazily-loaded run blocks are fine, but it's very easy to introduce unintended behavior with race conditions between different values for the same settings specified in different config blocks. Config blocks are for setting up behavior before an app bootstraps. If you need to change behavior after bootstrap, you should expose this in the service itself, not the provider.
Yes, this means you might have to re-write existing code that uses config blocks incorrectly. The good news is that your app becomes easier to understand.
Can you give me a specific example where it's somehow desirable to lazy-load a module with a config block?

I told all this because I believe this is a use of lazy loading you guys have not considered, all this proposal seems to be based on the idea of lazy loading components that are previously known, for performance reasons, reduce footprint, etc. But what about if I want to lazy load some modules dynamically, that is modules not known at coding time?

This is a use case that I have specifically considered. See this comment: https://github.com/angular/angular.js/issues/11015#issuecomment-77318320. In the future, I'd recommend reading the entire thread before commenting.
The "ng-allow-dangerous-lazy" option is a direct result of this discussion. Apps that want this level of dynamicity at the expense of being easy to reason about can use it. Most apps know ahead of time all possible injectables, hence the placeholders.

Can you give me a specific example where it's somehow desirable to lazy-load a module with a config block?

Loading an isolated app that has its own routes. This is our primary use case for lazy loading.

Loading an isolated app that has its own routes. This is our primary use case for lazy loading.

The New Router lets you re-configure it at run-time. It will soon have a shim that lets it use ngRoute's DSL. In theory this will address your concern, correct?

@btford yep should. You're smarter than you look ;)

@btford
Sorry I did a quick read of comments and didn't realize the one about the plugin system :(
I know config blocks could introduce race conditions but my point is that without config blocks any module that depends upon libraries with providers could potentially not be compatible with lazy loading.
There are a lot of great libraries out there that use providers, ui router for example. In my opinion trying to find and solve specific cases seems a waste of time, if lazy loading allow the use of providers for lazy modules good, if not and we are aware of the limitations is good too.
Correct me if I am wrong but this proposal means that for a library to be usable with lazy loaded modules must port all/some/part/none configuration logic from providers to services like the new router service you are mentioning.
Honestly speaking I don't mind that on my components, as you say there are advantages on that and probably I have implemented wrong uses for providers.  But I understand it could be not very interesting for library owners out there to do a big refactor in their code to make their libraries usable under lazy load. Which in turn could make this feature not worth to be used instead of the existing solutions out there
Regards, Raúl

I forgot to ask for constants, if no config blocks are run, that means a lazy loaded module can not use constants??

module that depends upon libraries with providers could potentially not be compatible with lazy loading

Yes, if the library is using config blocks in a way that is not intended.

There are a lot of great libraries out there that use providers, ui router for example.

The mere presence of a provider is not a problem. Also you would never lazy-load UI Router. You'd always need it upfront.

Correct me if I am wrong but this proposal means that for a library to be usable with lazy loaded modules must port all/some/part/none configuration logic from providers to services like the new router service you are mentioning.

This isn't correct. Any library you lazily load that requires reconfiguration at run-time must be re-written just for those services that require configuration. This will mean changing just a few lines of code, which is a small price to pay for determinism.

But I understand it could be not very interesting for library owners out there to do a big refactor in their code to make their libraries usable under lazy load.

Please show me an example where you'd need to do a ton of refactoring.

I forgot to ask for constants, if no config blocks are run, that means a lazy loaded module can not use constants??

This is incorrect, they'll still be useable post-config phase.

The mere presence of a provider is not a problem. Also you would never lazy-load UI Router. You'd always need it upfront.

I think his point is that ui-router states are declared by registering them with the ui-router state provider, which obviously must happen in the config block.  Any lazy loaded user modules that register states with ui-router would have to be reworked to do so at runtime.

Right, but lazy loading was never officially supported. Backwards
compatibility with existing hacks is not one of my goals here. And again,
the changes to user code would be minimal.
I feel like this thread is going in circles. If you have a specific,
concrete case where it would be difficult for a third party library to be
lazy loaded, and where it cannot be easily adapted, feel free to share.
Otherwise please make sure that what you post hasn't already been
discussed. Thanks!
On Sat, Mar 28, 2015, 11:55 Chris Thielen<EMAIL_ADDRESS>wrote:

The mere presence of a provider is not a problem. Also you would never
lazy-load UI Router. You'd always need it upfront.
I think his point is that ui-router states are declared by registering
them with the ui-router state provider, which obviously must happen in the
config block. Any lazy loaded user modules that register states with
ui-router would have to be reworked to do so at runtime.
—
Reply to this email directly or view it on GitHub
https://github.com/angular/angular.js/issues/11015#issuecomment-87282888
.

Right, but lazy loading was never officially supported. Backwards
compatibility with existing hacks is not one of my goals here

Fair enough, no more complaints on my part then

you need the config block if the lazy loaded module defines a decorator, but I'm not sure if there is a way to do that

@btford do you have a current implementation of this I can start playing with? I've followed this up to this point.

Eyes @btford
Eyes OP - Loading new code section and placeholder syntax
Eyes Counter proposal 1
:smiley:

I feel like this thread is going in circles.

@btford on the contrary, it has never been so clear.
If one takes the time to read it all.
I believe the doubts expressed by @raul-arabaolaza are very representative of the community anxiety towards AngularJS progress when it comes to maintaining large, complex systems.
Thank you both for the exercise.
@btford can you please improve your original post so that it incorporates the enlightened discussion?
Under "Run and config blocks":

that it does not throw if a module with config is lazy loaded (despite your comment it should throw if you try to add a module with config blocks)

Any library you lazily load that requires reconfiguration at run-time must be re-written just for those services that require configuration.

[constants] they'll still be useable post-config phase.

You might also rethink the // this example is silly, maybe present a more real world one.

Question about the new router in 1.4:
Why can't the lazy loading be convention based and follow the structure under the components folder?
Meaning, if you navigate using the router and activate a component, can't you just load the top level controller for the component at that point? Ideally you shouldn't have to reference the top level controller using a script tag. Upon instantiating the controller it would be ideal if all the downstream dependencies would be loaded and instantiated at this point as well (services, directives,etc). Again without the need for script tags in index.html. Given how Angular 1.x DI works I suppose this solution would require all downstream resources to be combined into a single file though. I was hoping the new router would function more like Durandal. The router config seems almost identical to Durandal routing, so it seem like it would be possible to support a more seamless RequireJS-esq DI here. It seems a bit odd to me to specify placeholders etc.

The option to load new modules into the injector will be part of 1.6.7. However, it's slightly different from the original proposal. Read more here: https://github.com/angular/angular.js/commit/34237f929927295392bbb1a600e78cbde581839a

Nice! It's funny to see that it doesn't take much code to do that when it's inside of the framework :)


Firefox snap does not run from vnc session

from what i can tell, snap only wants to run in a user slice, but vncserver won't run as a user service


Generated from 6ef5a66ea61ac5fb0d509eac0ebfb63e3eb016e2

updated web package - don;t merge yet

Can one of the admins verify this patch?

It doesn't look like we are, but if we're adding a new api version, we should remember to update the package_service_mapping,json entry for azure-mgmt-web to reflect the new reality.

@scbedd just modifying one of the older versions to make it easier to use 2018-11 version.
not sure if I will release this one or not yet. anyway I am going to look into package_service_mapping.json to make sure I fo everything correctly :-)


eth-json-rpc-provider: Replace use of any with proper types (non-test files only)

Look for the following string in non-test files to find these: // TODO: Replace `any` with type
At time of writing, there were 2 instances.

The any usage here occurs in the send and sendAsync methods of the SafeEventEmitterProvider class. Both methods are slated to be deprecated but not removed by this proposal (Align provider with Ethereum request libraries).
Therefore, we could replace the TODO and eslint-disable annotations with something like the following and close this ticket:
// @ts-expect-error This deprecated typing is being preserved for backward compatibility.

This can probably wait until the provider alignment proposal moves forward, and we can be certain that send/sendAsync will be sunsetted as legacy methods.


Everything except canvas disapearing on click on chat log

Without clearing chat log when damage drop-down or show-the-math is clicked everything except canvas disapears.

Yeah.  And we have no idea why.  The only solution we have, at the moment, is to clear the chat log and refresh.

Interestingly, when I have chat using PopOut! there's no issue.  When I leave the chat as a normal FVTT UI window, clicking on damage drop down does nothing (won't expand or collapse).  Either way, no issue with anything disappearing.
Tested on Brave, Chrome, and Edge - same results on all.


Home Page [Enhancement]

[ ] The text current animation loads twice for the first string.  Apply a different effect

[ ]  The text current animation loads twice for the first string.  Apply a different effect

Ya as I have made this effect. I will solve the bug.

[ ]  The text current animation loads twice for the first string.  Apply a different effect

Ya as I have made this effect. I will solve the bug.

Experiment with some other effects as well


"Data Warehouse is not currently supported in PREVIEW"

Can you please comment on this statement?
https://www.youtube.com/watch?v=DpAnFsvgkaw&feature=youtu.be demonstrates this feature in action.

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

ID: b4140ce1-5f43-81b2-36c4-cf90b2a72682
Version Independent ID: b4140ce1-5f43-81b2-36c4-cf90b2a72682
Content: Learn about Direct Lake in Power BI and Microsoft Fabric - Power BI
Content Source: powerbi-docs/enterprise/directlake-overview.md
Service: powerbi
Sub-service: powerbi-premium
GitHub Login: @Minewiskan
Microsoft Alias: owend

Thanks for your comment, @VitalyMCT. This issue has been assigned to the doc author for review.


XSS vulnerability in new filter redirects (CVE-2017-12098)

from https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0450

An exploitable XSS vulnerability exists in the add filter functionality of the rails_admin rails gem version 1.2.0. A specially crafted URL can cause an XSS flaw resulting in an attacker being able to execute arbitrary javascript on the victim’s browser. An attacker can phish an authenticated user to trigger this vulnerability.
The rails_admin gem has functionality which allows a user to create custom filters to find values within the admin interface. When a new filter is created using the UI, it redirects to a new url containing that filtering information in the form of
localhost:3000/admin/model?model_name=model&utf8=%E2%9C%93&f%5B password%5D%5B91178%5D%5Bv%5D=+%22%3E%3Cimg+src%3D%22%22+onerror%3D%22 alert(1)%22%3E&query=
This URL can them be used to phish an authenticated user and execute arbitrary javascript on their behalf.
This vulnerability was shown to occur using Chrome, Safari, and Firefox.

Fixed now, thanks for reporting.
I'll make a new release so users can use the unaffected version.


CORS Preflight Issue

Hi, just wanted to bring to your attention that the CORS OPTIONS preflight response does not include the required Access-Control-Allow-*_ headers (Access-Control-Allow-Methods, Access-Control-Allow-Origin, etc.). This results in some browsers/libraries are failing with generic network errors. A quick workaround is to leave CORS undefined in the service schema and handle the preflight requests with middleware.

Here we have tests to check the response headers in case of OPTIONS request:
https://github.com/moleculerjs/moleculer-web/blob/f375dbb4f8bff8aa16e95024e5c65463b626fa45/test/integration/index.spec.js#L2454-L2527

Indeed, it was the request originator at fault in my case after all - they were not sending the 'origin' header. This works like a charm.
Thank you!


cleanup(bigtable): split out howto_mock_data_api bazel rule

Using the same rule for howto_mock_data_api as the other bigtable_examples_unit_tests means that the union of the dependencies for all test are used by each.  This is causing a problem for an important google_cloud_cpp consumer.
So, split out the howto_mock_data_api rule so that we can minimize its dependency count.  This avoids the downstream issue.

This change is

I'm a little torn between making it simpler, and making the same as the others.

Which "others"? You can probably find places where we export separate lists to the same .bzl file, places where we use hard-coded lists in the BUILD.bazel and BUILD files, places where we use globs, and maybe other approaches that I have not thought of.
Of those, only globs look like a code smell to me. Not that globs are always wrong, just that they give me pause.

Yeah ... I thought there were more for test not in bzl_list-like restrictions, but I don't see that now.  In any case, I'm happy chat about looped bazel rules, generated .bzl files, etc.


iPad new action style provides no feedback when action touched

Currently we only render the action hover, and when the action gets clicked the hover background nicely changes.
I really like this new flow. However this does not work for the iPad because there is no hover when you are using touch.
What iOS seems to do for native actions is upon click show for 500ms inverted colors on the icon.
What do you think about using this approach for our actions for the iPad?

On desktop we currently have styles for: none, hover and active. On touch devices we should just have none and active. If the active isn't working properly, that's a bug. But I would not create yet another style just for touch.

Yeah it seems like the active is not working properly.
@joaomoreno let me know if you would like me to debug this further or if I can help?

I can't repro this, I do see action style when clicking them.

@joaomoreno can you double check when touching them?

I see the action feedback when clicking (via touch) but it sometimes decides to not go away until something else is clicked.

Yeah, we are aware of that corner case -> verified

Not so much a corner case, we should fix it, feels so ugly. 😢
But at least something is there yeah!

I created this issue so we track it
https://github.com/microsoft/vscode/issues/125482


Create a general Vertex and Edge class.

At the moment, when new topologies are created, tools to assembled a new topology graph easily do not really exist and are written from scratch for each class of topologies. It would be good to create a general Vertex and Edge class which can be used for any class of topologies. These won't have to be used, but should be available when desired.

I would like to work on this. My first goal is to get the MOC topologies working, but they will use a generalized Vertex and Edge that is inspired by the COF class.
Upon completion of the first few test cases of MOCs, the generalized Edge and Vertex can be implemented for other topologies?

Ok, sounds good to me!


[Windows 10 pro] Application getting cutoff if taskbar is vertical

Description
The menubar window is not full visible (bottom is getting cut off) with this arrangement:

Windows 10 Pro
3 monitors (1 laptop, 2 standalone)
Windows task bar is on the right side of the screen (vertical)

The hidden part of the app has roughly 200px height
Specifications

Menubar version: 9.0.1
Platform: Windows 10 Pro version 1083
Electron version: 9.2.1

Other information
Could be related to this PR: https://github.com/maxogden/menubar/pull/217
Screenshot

@amaurymartiny fyi

Yes, I believe that code was written before I became maintainer.

Maybe would another way be more effective?

Feel free to improve with a PR!

Ok. I'm going to remove this code. I've checked locally on Windows with 2 monitors. Seems that project works fine without this 'optimization'


Is it possible to access Audio buffers to retrieve info for a VUMeter?

Basically I would like to show a VUmeter with the audio volume/gain/amplitude being sent when streaming.
I could not found any way, I wonder if that is possible?
Thanks

Hello :)
I was kind of expecting this request.
There is a branch where you can get peak and/or rms value of each audio channels: https://github.com/ThibaultBee/StreamPack/tree/feature/vu-meter. I just rebased it.
The only things missing for now is that when preview is running, you won't get any value cause audio capture is not running and I still don't really know how to implement this part.
Regards,
Thibault

Hello :)
this is great! exactly what I wanted! thanks :)
I don't need the values while previewing but from what I can understand you can just startRecording on the AudioRecord and discard the Frames after getting the measurements.

Hi,
This is the issue: there aren't any audio frames when encoder is not running. It means that you can only access audio frame when StreamPack is live streaming.

What metrics do you have in mind?

latency, bandwidth, frame rate, bitrate. I am not sure if those are possible at all.

Do you use SRT or RTMP?
I guess it is quite easy to return latency, bandwidth and network bitrate with SRT, not sure about RTMP.

SRT 😄