Kubernetes services exposing host(worker) ports

What is the problem?
When I create a kubernetes public service(reached from the internet), all host ports are being exposed through the kubernetes IP service, not only using the port used in the kubernetes service.
How it should work?
Having a host having 150.165.A.B as IP address accessible through ssh over 22 port and creating a public kubernetes service which has 150.165.C.E as IP address exposing web servers over 80 port:

I should be able to perform:

$ ssh<EMAIL_ADDRESS>[OK]
$ curl 150.165.C.E [OK]

I shouldn't be able to perform:

$ ssh<EMAIL_ADDRESS>[FAIL]
$ curl 150.165.A.B [OK]

How to reproduce the problem:
Once I create a service and the VIP is added in the virtual_address, the virtual IP added in the managed interface, is responding to all processes that the host IP responds. For example:
Imagine a worker node that has 150.165.A.B as IP, and I'm able to connect this host through ssh
e.g.: $ ssh<EMAIL_ADDRESS>And I have configured the keepalived-cloud-provider to create service using 150.165.C.D/27 CIDR.
Consider that the service creation process will create a service which has 150.165.C.E as IP address, this will generate a keepalived.conf a file similar to the following
global_defs {
  vrrp_version 3
  vrrp_iptables KUBE-KEEPALIVED-VIP
}
vrrp_instance vips {
  state BACKUP
  interface eth0
  virtual_router_id 50
  priority 100
  nopreempt
  advert_int 1
  track_interface {
    eth0
  }
  virtual_ipaddress {
    150.165.C.E
  }

# Service: app-my-service
virtual_server  150.165.C.E 80 {
  delay_loop 5
  lvs_sched rr
  lvs_method NAT
  persistence_timeout 1800
  protocol TCP
  real_server <IP_ADDRESS> 80 {
    weight 1
    TCP_CHECK {
      connect_port 80
      connect_timeout 3
    }
  }
}

It will manage host's network interface like that
$ sudo ip addr list eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:26:b9:51:bf:79 brd ff:ff:ff:ff:ff:ff
    inet 150.165.A.A/27 brd 105.156.A.E scope global eth0
       valid_lft forever preferred_lft forever
    inet 150.165.C.E/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::226:b9ab:fe15:ba97/64 scope link
       valid_lft forever preferred_lft forever

After having this setup, you should be able to reproduce the scenarios described above.
Is missing any firewall rule to avoid kubernetes services which are using keepalived expose the real host services/ports?

Don't think this is a kube-keepalived-vip concern. It just creates a virtual IP that routes to the underlying host IP that it is assigned to. This uses purely layer 2 ARP broadcasts to advertise that the VIP can be reached by the same MAC address that the host IP has. Thus any port that is exposed on the host will be exposed on the VIP. You can just add all ports you don't want exposed to the firewall.


Failed PropType: 'fields'

Greets,
Using redux-form 4.2.0, I can't seem to get my component to properly connect to reduxForm. It's pretty straightforward right now -- I haven't even put together the inputs yet, because I can't get past the following three proptype errors:
Warning: Failed propType: Required prop `fields` was not specified in `ReceiverControlForm`.
Warning: Failed propType: Required prop `handleSubmit` was not specified in `ReceiverControlForm`.
Warning: Failed propType: Required prop `submitting` was not specified in `ReceiverControlForm`.

Here's the code for ReceiverControlForm.jsx in its entirety:
import React, { Component, PropTypes } from 'react';
import { reduxForm } from 'redux-form';

const fields = [ 'channel', 'label',
                        'readable', 'writable',
                        'min_value', 'max_value',
                        'min_label', 'max_label',
                        'value' ];

export class ReceiverControlForm extends Component {

  static propTypes = {
    fields: PropTypes.object.isRequired,
    handleSubmit: PropTypes.func.isRequired,
    submitting: PropTypes.bool.isRequired,
  };

  render() {
    const { resetForm, handleSubmit, submitting,
            fields: {
              channel, label, readable, writable,
              min_value, max_value, min_label, max_label,
              value
            },
          } = this.props;

    return(
      <form className="form-horizontal" id="receiver-control-form">

Test

      </form>
    );
  }
}

export default reduxForm({
  form: 'receiver-control-form',
  fields
})(ReceiverControlForm);

I get an identical error if I use the boilerplate from this page: http://erikras.github.io/redux-form/#/examples/simple?_k=8fovj7
Any suggestions are very welcome. I've been playing around with the code for a while but can't seem to get it working. Wondering if I'm missing something obvious.

Never mind. I was importing the undecorated { ReceiverControlForm } instead of the decorated ReceiverControlForm (ie: the default export) in the parent component ... I figured it was something simple.


Fix continuous integration badge

Looks like shields.io has updated the badge API, which requires the CI badge to be updated. See https://github.com/badges/shields/issues/8671 for details.

Fixed in #158.


Allow forward scheme for spring cloud gateway mvc similar to its webflux counterpart for declarative configuration using application properties or yaml

Is your feature request related to a problem? Please describe.
webflux gateway allows forwarding using dispatcher handler (ForwardRoutingFilter) declaratively using application properties and yaml. Similar capability seems not available in mvc version of it.
Describe the solution you'd like
Ability to use forward scheme to configure gateway routes in application properties or yaml files. Any before filters applied on the request should be visible in the forwarded target
Describe alternatives you've considered
HandlerFunctions.forward is available for DSL based configuration however it seems any before filters applied on the request is not visible to the forward target.

See HandlerFunctions.forward(). It should be available to configuration. Are you seeing otherwise?

Caused by: java.lang.IllegalStateException: Unable to find HandlerFunction for scheme: forward
	at org.springframework.cloud.gateway.server.mvc.config.GatewayMvcPropertiesBeanDefinitionRegistrar.getRouterFunction(GatewayMvcPropertiesBeanDefinitionRegistrar.java:197) ~[classes/:na]
	at org.springframework.cloud.gateway.server.mvc.config.GatewayMvcPropertiesBeanDefinitionRegistrar.lambda$routerFunctionHolderSupplier$1(GatewayMvcPropertiesBeanDefinitionRegistrar.java:145) ~[classes/:na]
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) ~[na:na]
	at org.springframework.cloud.gateway.server.mvc.config.GatewayMvcPropertiesBeanDefinitionRegistrar.routerFunctionHolderSupplier(GatewayMvcPropertiesBeanDefinitionRegistrar.java:144) ~[classes/:na]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.obtainInstanceFromSupplier(AbstractAutowireCapableBeanFactory.java:1257) ~[spring-beans-6.1.4.jar:6.1.4]
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.obtainInstanceFromSupplier(DefaultListableBeanFactory.java:951) ~[spring-beans-6.1.4.jar:6.1.4]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.obtainFromSupplier(AbstractAutowireCapableBeanFactory.java:1217) ~[spring-beans-6.1.4.jar:6.1.4]
	... 120 common frames omitted


[1pt] USGS coord accuracy code list data type

At least one site (TRYN7) has not been getting mapped, despite having all of the acceptable accuracy codes. This was caused by a data type issue in the acceptable_coord_acc_code_list in tools_shared_functions.py having 5 as a string instead of an integer.

I've made a fix on a feature branch and will make a PR.


vox oxygen toxicity, respiration changes

About the PR
We all knew this was coming, but it's coming today! (Maybe)
Vox take poison damage from oxygen and die in normal station air in 2 minutes. They get a TOXIC alert when breathing oxygen (this could be switched for the more specific "too much oxygen" alert icon, but I don't really see the need to give each toxic gas their own distinct alert)
They must breathe pure nitrogen (or any other nitrogen-containing but oxygen-free gas mixture, if those somehow exist somewhere)
Since it requires taking off your mask, they can't eat and drink without taking damage unless they have access to a nitrogen-only environment, but they can survive a meal in oxygen.
Eating your emergency cube and drinking your emergency drink, then immediately turning internals back on results in about 21 poison damage. 2 dylo pills basically clear that up, although that means taking off the mask again briefly so might want to add a charcoal pill for good measure. Or preferably just ask for the dylovene to be injected instead.
Note that a vox succumbing to oxygen toxicity will spend a human-equivalent time in the crit state and will after dying still be revivable, because in crit state mobs stop breathing. Thus about half of their damage will be airloss instead of toxin.
Vox now exhale ammonia. Due to this, breathing ammonia is now more dangerous to them (since it asphyxiates them even in moderate quantities), while CO2 is now harmless.
New spawnable vox variant that is already equipped with breathing gear and N2 tank, for admin ease of use (note that currently the internals must still be activated by hand, if they are spawned in an oxygen atmosphere and they will likely take a little poison damage even if you do so immediately)
Why / Balance
There has been somewhat of an increase in admeme voxspawns, so lets not establish their current respiratory details as the normal. Vox being hurt by oxygen is in line with how vox are expected to be, based on SS13 (where they apparently die EVEN FASTER)
Ammonia was honestly just a result of me being bothered by the fact that if they would exhale either CO2 or N2O, where would the oxygen come from in high and constant enough quantities to be constantly exhaled? Plus trashbirds being naturally stimky (as far as humans are concerned) is also kinda funny. In practice, it will likely never actually matter due to vox either breathing N2 safely from a bottle, or dying to station oxygen. As far as others are concerned, the small amounts of ammonia will be handled by the scrubber system same as CO2 would be. This is mostly just a thematic change
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog
:cl: Errant

tweak: Vox now take significant damage over time while inhaling oxygen.

ADMIN:

add: When spawning vox for admemes, they should be given/spawned in a nitrogen-filled space if possible. If they must be placed in normal air, an alternate vox prototype now comes with breathing gear and N2 tank already equipped, but the internals must be turned on via right click and even if you do this instantly they will still probably take ~4 poison damage from the air, so heal them afterwards.

Probably doesn’t need a normal CL since Vox currently aren’t player facing at all

ith vox.

Probably doesn’t need a normal CL since Vox currently aren’t player facing at all

Well since they don't have AI, the only way they would ever be in play is under the control of players. They are just very rare due to being admeme only. But I felt players ought to know about a change this lethal both for when picking the ghostrole and when encountering them. I will remove the player CL if there is consensus its not necessary/admin will have to brief them anyway.

Shouldnt Vox spawn in with a face mask and nitrogen pack already setup?

Shouldnt Vox spawn in with a face mask and nitrogen pack already setup?

I only mentioned it in the admin CL, I did add a vox prototype that has breathing gear equipped. But it needs to be toggled on by hand after spawning.
I need #25083 for auto-activation


Fix the Overlapping Issue on the CTA Button in Mobile

Description
The issue at hand is that the banner component at the bottom is causing overlap with the call to action button, obstructing it from being properly visible and accessible to the user. The goal of this ticket is to resolve the overlap and ensure that the call to action button is clear and functional for all users.
Device Details
Note 20
412x915
Screenshot

I'm interested right away 🙋♂

@ysnbyzli,
Tesekkurler Yasin, biraz once PR olusturdum (https://github.com/acikkaynak/deprem-yardim-frontend/pull/159). Goz atabilir misin?


Adopt Material Design 3 / Material You

I'm sure you're tracking the pulse of material design standards like me and others. That being said, material ui version 3 is out.
We should track MUI being migrated from Material Design v2 to Material Design version v3.
I'm sure they'll be a few tickets that come out requesting the adoption, so I figured this ticket could act as a stub and catch-all for MUI support for the design language's latest update.
Cheers
References

MD 3 Docs https://m3.material.io/
MD 2 Docs https://material.io/
Ionic's discussion on the problem https://github.com/ionic-team/ionic-framework/issues/24282
Vuetify's discussion on the problem https://github.com/vuetifyjs/vuetify/issues/14332
Quasar's discussion on the problem https://github.com/quasarframework/quasar/issues/11139
Google's discussion on the problem https://github.com/material-components/material-web/issues/2441
The docs traffic on MD 3 vs MD 2: https://www.similarweb.com/website/m3.material.io/?competitors=material.io
Material Design traction on Figma MD 2 Figma file vs. MD 3 Figma file

January 12, 2022: MD2 4.8k stars 256k copies, MD3 1.9k stars 39.6k copies
March 24, 2022: MD2 5.6k stars 277k copies, MD3 4.2k stars 91k copies
August 23, 2022: MD2 6.5k stars 307k copies, MD3 5.8k stars 132k copies
October 6, 2022: MD2 6.8k stars 315k copies, MD3 6.6k stars 155k copies
December 20, 2022: MD2 7.2k stars 327k copies, MD3 8.9k stars 214k copies

React Native Paper: https://github.com/callstack/react-native-paper/issues/3126
Flutter https://github.com/flutter/flutter/issues/103537
Angular Material: https://github.com/angular/components/issues/22738

Design kits

https://github.com/mui/mui-design-kits/issues/135
https://github.com/mui/mui-design-kits/issues/103

Real adoptions of Material You in the wild?
Desktop

https://relay.material.io/
https://httpie.io/app feels inspired by it
Gmail partially, which feels relatively yolo
Others?

Mobile

Google Pixel Phones. "Canalys puts Google fifth in U.S. phone market share, with just a 1.7% in Q3 2022." source. It's insignificant. All the other phone manufacturers skin Android, so don't use Material Design 3.
Others?

Thanks for creating the issue. Let's use it as a stub 👌

is this being considered?

Was about to start my own feature request, but found this. I think material v3 does look way more expressive and vivid than v2, and Google's own material web components is also in the progress of implementing Material You (https://github.com/material-components/material-web/issues/2441).

Hi, if nobody wants to take up this task, I can plan and gradually migrate some mui components to material v3 standards. @mnajdova, is there anything blocking that needs to be completed before migration can start? If not, I think we can start with a checklist of components in order of importance and visual difference from material v2 -> v3.

It is a breaking change, so I am not sure that we can start with it right away (at least we cannot update the components which are part of @mui/material). We could try to adopt the styles to some of the components that we have inside @mui/material-next - this is our experimental package that depends on @mui/base that we envision will be the replacement for @mui/material v6. In my opinion this should be a good start. @mui-org/core what do you think?
@cryptoAlgorithm feel free to kick off this effort if you want to. Check first which components we already have in the @mui/material-next package and try to experiment with some of those if you want to.

Ok, great. Maybe this can be introduced as part of the material-ui v6 update? Since by then, material v3 styles should be quite common across sites using material design. We might want to wait and see how Google handles this in their own Material Web Components library, and how they actually look.

We could try to adopt the styles to some of the components that we have inside @mui/material-next - this is our experimental package that depends on @mui/base that we envision will be the replacement for @mui/material v6. In my opinion this should be a good start. @mui-org/core what do you think?

Agree. Just note that material-next is our experimental (playground) package. We intend to test different shapes of the API there and introduce breaking changes without notice, so it's not safe to depend on it in production.

Hello my friends, if you need MATERIAL DESIGN 3 how about https://www.beercss.com?

@leonardorafael That implementation has a few issues:

The implementation does not follow material standards fully: Buttons are the wrong shapes, animations are there when they shouldn't be and it looks like the sizing and paddings aren't correct
That doesn't seem to be a react library on quick inspection, which doesn't fit into the purpose of Material-UI
The ripple animation seems to be flawed: it only works on the first click, and only originates from the centre of the clickable area.

One thing thats done well (from the few available samples) is the color palette generation. I don't know if its following google standards, but it seems close. Maybe thats one thing that can be adapted, but I don't know if thats required for such a UI library

It would be nice to somehow get early support for MD3 design tokens in advance of the rest.
The biggest leaps forward with MD3 compared to the design tokens available by default in MUI today are:

New typographic tokens. The system (5 semantic choices × 3 sizes) is far more intuitive, the type scale is actually usable out of the box (MUI's built-in h1 is an insane 96px, whereas MD3 tops out at a much more reasonable 57px), and the responsive type sizing is improved (though I don't know if the tokens are actually available yet).

New color tokens. The 0-100 tone system eliminates the codependence between the colours you pick and the tones you choose, because luminance is normalized; if you pick primary[40], you're guaranteed to get a usable tone no matter the input colour. It also helps accessibility; MUI's current info and warning colours fail on WCAG 2.0 AA contrast ratio, whereas presumably a new info[500] would be guaranteed to pass.

Be warned, MD3 is still a bit half baked, for instance there's no saturation control during palette generation; you can't really choose whether you're getting super-pumped-up colours or pale tones, for instance. And some of the results are way too colourful for desktop devices.
But if MUI gets involved sooner than later, maybe there's an opportunity to help them make the right choices!

Ideally, MUI should (or start efforts to) adapt Material v3 as soon as possible since its the most popular react material library, and might give MUI a head start over potential competitors (including google's own library). Material v3 support would be quite enticing since I foresee the popularity of the new standard increasing after android 12 actually becomes mainstream, and people might be attracted to the library mainly for this reason.
I honestly don't think implementing the whole palette generation and color extraction functions are feasible, it should be left to the dev to implement such generation themselves. These will keep the dependancies and size of the library reasonable and not add additional unessential bloat that not everyone will use.

To be honest, I'm not so sure that MD 3 will have a lot of traction. I'm eager to wait for positive signals before committing to this effort. The context seems different in 2022 than it was in 2016:

Does MD 3 looks great like MD 1 was when end-users had smaller screens with less resolution? Personally, it's a clear no and the same answer goes from @mbrookes.
Before MD 1 (OS 5 - Lollipop 🥰), it was looking ugly (OS 4.4 - Kit Kat 🙈) so easy. I think that it will take some customization effort from our end to make it appealing. My experience so far is that Google's UI looks better than what http://material.io/ ships.
Is the Pixel the only phone that really uses Android now? The large majority of the phones sold are based on a custom UI Samsung (One UI), Xiaomi (MIUI), OnePlus (OxygenOS).
Most of the Android apps I use now are no longer based on MD. It used to be a lot more popular, I recall. I feel that it was pushed on purpose by Google, to avoid brand dilution.
MD 3 is currently targeted at mobile but most people use MUI for desktop apps.

I fully agree that the material standard would need to be slightly adapted to look great on desktop-sized websites/web apps, however it seems like the material v3 standard takes into consideration slightly larger screen sizes, like the navigation rail etc. Also, I think the standard google is showing at their reference site https://m3.material.io/ seems much better than the reference v2 site (not even google follows it 😆).

One interesting thing is they seem to already be using web components in the material v3 style for that website, which begs the question: why isn't there any big progress in their official material web components library?

why isn't there any big progress in their official material web components library?

@cryptoAlgorithm It doesn't seem to be documented nor in CI workflow (built), but you can see that there's work being done! If I will be able to use that code and check which components are ready to use, I will let know there. Meanwhile, I encourage everyone who's interested to check it by themselves.
What might be meaningful to this topic is that these components are written using Web Components API, which (I think) means that there's not going to be much work required to make React (or other UI library) wrapper.
From my reading, it seems to be a way to make design systems that are future-proof and not bound to any framework.

https://ionic.io/resources/articles/burger-king-design-system
https://youtu.be/cNbSlmCrozg
https://stenciljs.com/

I fully agree that the material standard would need to be slightly adapted to look great on desktop-sized websites/web apps, however it seems like the material v3 standard takes into consideration slightly larger screen sizes, like the navigation rail etc. Also, I think the standard google is showing at their reference site https://m3.material.io/ seems much better than the reference v2 site (not even google follows it 😆).

One interesting thing is they seem to already be using web components in the material v3 style for that website, which begs the question: why isn't there any big progress in their official material web components library?

I think Material v3 has uses components to do more things. For example, Chips have expanded and Cards are used to contain everything. To me, the design is meant as a responsive framework for all screen sizes, from mobile first, to foldable devices, to 4k desktop monitors.
I've already implemented material v3 atop MUI v5...the main trick was follow their opacity rules to make cards and chips look and feel the variants described in the specs. I like it by the way. Everyone who saw my app, loved it too.
The big diff I see is that MUI will need to help developers create a triple color theme. From there, Cards have 3 variants and Chips have several variants too.
The question becomes, what does MUI do with the other components that are in material v2 but not in v3? I say keep em, though have them follow v3 guidelines, from a theming perspective. This way devs have everything they need and more to build V3 specifications into apps.

@NawarA anyway you would share your implementation of material v3 into mui v5?

not sure how I'd go about merging with the MUI 5 repo.
From an implementation perspective, the main place to start is having a way to give a user 3 colors for their theme.
From there, Cards and Chips are components that have variants. Each variant uses the 3-color theme, opacities, and hover effects to create the effects described in the v3 specs.
I have my triple color theme hard coded atop MUI v5 (as a separate namespace).  From there, I created a custom Card and Chip components that a variant as an input, and return the correct component design / behavior as an output.
I could create a repo that has this running as an example...though I'm not sure how to merge that into MUI v5...even though its built on MUI v5. Any guidance would be helpful

@NawarA we use the @mui/material-next package for experiments, you can find the source code in https://github.com/mui/material-ui/tree/master/packages/mui-material-next

Hello everyone.
I share with you my own implementation of the Material You theme in MUI using the createTheme function and the official google Material Color Utilities library to generate the dynamic theme.
Project Repo
I hope it is useful to you.
Default Light

Default Dark

Color System

I disagree that Samsung's theming is not acknowledging Material 3, but rather I'd point out that not everybody sticks to Samsung's apps exclusively. And Samsung does tend to adapt their own to the latest libraries from google (once they're published and tested), so usually a year or so out.
but in the meantime, Google's own apps will be adopting this. Whether or not they ever tie in the color theme to the primary color of the Samsung theme, I can't say. i wish they would, of course.
in my case, the idea that a "perfect" theme can be constructed from just 2 colors is very appealing - I have a music app where I like adapting the primary/secondary color as extracted from the album cover art. If the theme could automatically figure out that it needed light/dark text based on the colors, it would save me some very bug-prone calculations I currently have to do to implement that.
BUT I acknowledge that MD3 is all in Java (if it is released at all in source form) and so it isn't easy for an independent company to figure out the same algorithms they're now applying.

I'm inclined to think MUI should look at the palette generation of beercss - even if it isn't perfect, it is still a start, a set of algorithms that can be tweaked. Hard to know exactly what it would take given that Google i don't think has formally published its algorithm (thus why i'm wondering if the Android source code really includes this aspect of Material 3 to be extracted). Again, I think the tougher problem for MUI users NOW is knowing and having to state if the FG color should be white or black depending on the rest of the context.

@acroyear The Material Foundation has some implementations of their algorithms + utilities for the MD3 color system here https://github.com/material-foundation/material-color-utilities

thanks.

The beercss palette is a reverse engineer from material foundation theme builder site. It's exactly the same algorithm. After one year, Google finally release the lib on GitHub, and we should use it too. 👍👍

I think the tougher problem for MUI users NOW is knowing and having to state if the FG color should be white or black depending on the rest of the context.

getContrastText in the undocumented colorManipulator does exactly that, but perhaps there's a nuance that I'm missing?

I think the tougher problem for MUI users NOW is knowing and having to state if the FG color should be white or black depending on the rest of the context.

CSS color-contrast() was meant to help solve for this as soon as this year, but unfortunately it looks like it got bumped before that article even published.

There's colorManipulator's getContrastText, but. apologies, I'm a bit out of touch with what's in the theme or public API...

Well... I've created a small template for Material You (Material Design 3). You can have a look at it
Project Repo
And here's the M3 Color Picker: Color Picker
Color Picker Repo Link: Repo Color Picker
This is made with TypeScript and Vite.

So, what is the plan here?
currently they are two options:

https://react-m3-demo.web.app/Components
https://www.beercss.com/

but nothing official from MUI.
How do we proceed?

Every startup’s design is probably better off by conforming to a UI/UX, familiar to the users.
MUI Joy, with all respect, doesn’t offer that. It’s not Material Design by Google, not Fluent UI by Microsoft, and not Human Guidelines by Apple.
So if you agree with the argument, then MUI will become the same type of organization with Joy, serving own goals first and the community second as the majority of the community is better off conforming to familiar to the end users UI/UX patterns.
Please MUI, consider to adopt Material Design 3 sooner as it should be in MUI’s best interest as it is in the best interest of your community

Every startup's design is probably better off by conforming to a UI/UX, familiar to the users.

@o-alexandrov I'm a believer in this as well. It's exactly why I initially got involved in Material UI. Now, when it comes to Material Design v3. As far as I know, it has little market adoption for the end-users compared to Material Design v2. Is there a desktop website with a significant audience that truly embraces it? I doubt Gmail qualify. Or on mobile, outside of the Google Pixel phone, who is using the default look & feel of Android? It feels like we have time.

MUI will become the same type of organization with Joy, serving its own goals first and the community second

To be clear, Joy UI was not created for the design needs of MUI as an organization. I mean, we are not using it for one of our products. It was created to serve the community, its goal is to reach a point of mass adoption to get the UI/UX familiarity effect for the end-users. Either by becoming very popular through beauty as the main driving factor or by taking strong inspiration from existing popular patterns. We took a route closer to the former option (more creative) because Material UI is already on the latter option (following Material Design).

It might be safe to expect, and we've been broadly discussing this internally, that Material UI won't go through a significant overhaul any time soon to be on par with what's currently out there of Material Design v3, simply because it's not yet mature and fully fleshed out yet. As @aaronadamsCA points out, there are misaligned expectations with what was once announced and what's available today in their documentation. However, as others shared (thanks @ZakAlbert!), it's very much possible to have a custom Material UI theme that replicates the newly introduced designed direction of MD v3 and that may be something we want to make easier to use/access somehow－all using the current available theming customization features on Material UI v5.
Regarding Material UI x Joy UI, they're not at risk of out-competing each other. As @oliviertassinari pointed out, Joy UI is a new take on the UI component library game to explore both a new design direction as well as new features and ideas. Our goal, in the long run, is that both of them share many of the same patterns and general DX but with the main and biggest difference being the design direction: Material UI obviously follows Material Design (for the time being, v2) and Joy UI follows one that we're proposing ourselves.
Hope all of that makes sense!

Please also consider that a lot of current applications also have a mobile applications.
Companies want to use the same design system in both - web and mobile.
Bigger companies have also a lot of projects for web, written not always in react.
Biggest Material lib for react native already supports Material You. Flutter framework and others also.
Summing up Material You introduce changes even in colors so currently is hard to maintain a brand colors/system for all products if you rely on Material UI, especially when there is no plan to implement that in nearest future.
Is great you are introducing Joy UI, but for bigger players probably you will need to make libraries also for other frameworks and mobiles.
BTW, You all making such excellent work 🔥, just part of community have different needs.

Biggest Material lib for react native already supports Material You. Flutter framework and others also.

@unpxre Awesome, thanks for mentioning it. I have added https://github.com/callstack/react-native-paper/issues/3126 and https://github.com/flutter/flutter/issues/103537 as benchmarks in this issue's description. It seems that they both when with the option to provide MD2 and MD3 as supported options (not dropping one for the other).
These two PRs could maybe be of some inspiration for us: https://github.com/flutter/flutter/pull/108704, https://github.com/callstack/react-native-paper/pull/3108.

@unpxre Maybe you could add Material You to your best project: https://zseis.zgora.pl/ XD
BTW, pozdro z elektrona :D

For everyone interesting in chiming in, I've created discussion for the implementation strategy for Material You in @mui/material - https://github.com/mui/material-ui/discussions/34738. Feel free to leave your thoughts there.

Material V3 will be availbale as web components build with lit v2 lit.dev. The lit build environment also provies a react componet wrapper, that should make it easy to use their componets in what ever platform; the web components are platform antagonistic. Many others are following a similar path. Adobe has spectrum https://opensource.adobe.com/spectrum-web-components/ . SAP has UI5. IBM has Carbon. Microsoft started are also building their next generation web components, but using Faster instead of lit. Seems like the situation is way different now, and I am wondering if it is worth the effort to export Material v3 to mui.
Check out https://lit.dev/

Material V3 will be availbale as web components build with lit v2 lit.dev.

@nikolaidk Do you have more references on this? Who is implementing Material Design 3 with lit?

Seems like the situation is way different now, and I am wondering if it is worth the effort to export Material v3 to mui. Any thoughts on this?

We could consider creating a Vue and Angular wrapper on top of Material UI. For these, the wrapper would need to use Preact for the runtime to keep the bundle footprint minimal. However, the DX won't be as good as with a native implementation (I don't see how it could be, but maybe there is a way).
But maybe your question is about doing the opposite: creating a React wrapper on top of a Material Design 3 lit implementation. I was wondering about something similar 5 years ago: #6799. I think that it's the same issue: "the DX won't be as good as with a native implementation".

Angular material v15 is integrating with the material-web-components
https://github.com/angular/components/issues/22738

Hi oliviertassinari
I have have been digging into Googles repositories :)  lit is a google project and used to build Material v3 On a sub page under https://m3.material.io/develop/web there is a link to the repository holding their V3 web components. Current state of work is available here material-web: its all about lit and platform antagonistic components. Look for lit imports like this import {ReactiveElement, render as litRender, TemplateResult} from 'lit';  Also take a look at this https://www.npmjs.com/package/@lit-labs/react Looks like there is all ready working in progress to make the adoption of lit components in react fairly easy.

For everyone that wants to check out the first component implementing the Material You design system, check https://codesandbox.io/s/focused-sid-xy7j09?file=/package.json.
The components will be hosted under @mui/material-next which is a new, experimental package. We are open for any feedback on the components/theme structure.

@mnajdova Seems that the ripple effect is missing/not obvious in Android.
BTW Will material-ui support the Material 3 ripple effect (I can't find it in the spec)? It seems costly to GPU.

@mnajdova Seems that the ripple effect is missing/not obvious in Android Chrome.

Based on the spec for Material You, the buttons don't have ripple effect. I found it strange too. I was thinking to wait for a feedback for the community about whether we should support it.
For example, they have it in the Fab: https://m3.material.io/components/floating-action-button/specs#d1d87229-b180-428e-9ccf-86d4a91a4901
But not in the button: https://m3.material.io/components/buttons/specs#e9bfb85f-8f4e-4d6e-99f5-28c8d6439365
(check the pressed state). I would be up for adding it everywhere.

BTW Will material-ui support the https://github.com/flutter/flutter/issues/82850? It seems costly to GPU.

We don't have plan for it at this moment, but we could wait and see what will be the community's opinion on this. As far as I could understand on the MD3 spec, they are not mentioning it.

@mnajdova Seems that the ripple effect is missing/not obvious in Android Chrome.

Based on the spec for Material You, the buttons don't have ripple effect. I found it strange too. I was thinking to wait for a feedback for the community about whether we should support it.
For example, they have it in the Fab: https://m3.material.io/components/floating-action-button/specs#d1d87229-b180-428e-9ccf-86d4a91a4901
But not in the button: https://m3.material.io/components/buttons/specs#e9bfb85f-8f4e-4d6e-99f5-28c8d6439365
(check the pressed state). I would be up for adding it everywhere.

BTW Will material-ui support the flutter/flutter#82850? It seems costly to GPU.

We don't have plan for it at this moment, but we could wait and see what will be the community's opinion on this. As far as I could understand on the MD3 spec, they are not mentioning it.

Perhaps is missing on the documentation but buttons do have a ripple effect. Good place to check actual implementation of the design is the Compose Material Catalog app for Android from Google.
Regarding the sparkling ripple that was introduced at the beginning of Android 12, already during the Beta version it was progressively removed. I had completely forgotten about it as I haven't seen them in Android 13, they don't seem to have continued with it.

Apologizes then, my bad. The ripple is coming back in https://github.com/mui/material-ui/pull/35299. Here is a preview: https://codesandbox.io/s/jovial-currying-g7u9m0?file=/demo.tsx

Working on this in my spare time https://www.material-toys.com/

Chrome is making steps toward adopting Material You https://twitter.com/Leopeva64/status/1618509963776888832.

It's open since Oct 27, 2021 and allways no solution? Please - upgrade MUI to Material 3 now.

It would be a good business model to adopt Material 3 and offer updates to Material 2 under proprietary licenses only. Like Oracle did with Java.
That way everyone will be happy.

It would be a good business model to adopt Material 3 and offer updates to Material 2 under proprietary licenses only. Like Oracle did with Java.
That way everyone will be happy.

lol

It would be a good business model to adopt Material 3 and offer updates to Material 2 under proprietary licenses only. Like Oracle did with Java.

Adopting Material Design v3 is part of our roadmap.
Here is one possible execution path, with a guessed timeline:

Hire one Design Engineer, to own the work on Material Design. Q2 2023?
Have the person focus on getting @mui/material-next to move forward, building with Base UI and Material Design v3. Effectively, laying the foundation for Material UI v6. Do as much as possible without the need for breaking changes in Base UI. Q2 2023?
Once we need to do breaking changes in Base UI, pause all work on the stable release of MUI Core v5 and move all effort to MUI Core v6. Q4 2023?
A stable MUI Core v6 release, there we would want RSC support. Q1 2024?

cc @mnajdova for thoughts, I think that other variations would make sense.

Thank you all for the work on this 🙇🏻
Would it be possible to create a roadmap to show the advancements in adopting Material Design v3? :) I'd really appreciate it.

@oliviertassinari the plan proposed make sense.

Hire one Design Engineer, to own the work on Material Design. Q2 2023?
Have the person focus on getting @mui/material-next to move forward, building with Base UI and Material Design v3. Effectively, laying the foundation for Material UI v6. Do as much as possible without the need for breaking changes in Base UI. Q2 2023?

Done, we are starting next month (June) to work actively on this - adding more components to @mui/material-next. We will try to keep the API of the components as close to v5 as possible, unless Material You has different nomenclature.

Once we need to do breaking changes in Base UI, pause all work on the stable release of MUI Core v5 and move all effort to MUI Core v6. Q4 2023?

Most probably, cannot guarantee on the actual timing, but looks like a good estimation.

A stable MUI Core v6 release, there we would want RSC support. Q1 2024?

At the earliest yes, for the RSC I am starting to think that it will need to be in a form of opt-in (using some zero runtime CSS-in-JS), and provide a different API for emotion, for e.g. one that doesn't depend on context - I am not sure if it will be possible but it's one option.

Would it be possible to create a roadmap to show the advancements in adopting Material Design v3? :) I'd really appreciate it.

We already added it to the roadmap, this month we will create the definite list of components we want to add this quarter.

I think that other variations would make sense as we could already do one stable release at step 2, and another major at step 4

I would be also curious to hear the community opinion on this. In terms of what would be the preferred upgrade strategy:

v6 containing upgrades for both Material You and new styling solution (as an opt in if possible)
v6 containing upgrade for Material You (with the existing styling solution), v7 to ship the new styling solution (as an opt in if possible)
v6 containing upgrades for the new styling solution (as an opt in if possible), release v7 with the Material You updates

In my opinion I would go with option 1, as I weight these two updates equally important (desirable), but I may be wrong in this assumption. Here are some of the related issues: RSC - https://github.com/mui/material-ui/issues/35993, zero-runtime CSS in JS - https://github.com/mui/material-ui/issues/34826, Nextjs 13 app directory support (related to RSC) - https://github.com/mui/material-ui/issues/34905

I'd prefer v6. Material You would be the most pressing for me.
I'd be especially happy, if the API would remain similar to the current version (of course if patterns are different, API changes would be totally acceptable).
The new styling solution would surely be appreciated, but it's not a very pressing matter for me.

Ideally I would say option 1, as I would like to have both on the next release, but it seems that way the aim is Q1 2024 for v6.
So in the case one could be prioritized over the order to have a sooner v6 release I would then choose option 3, as having a zero runtime solution would provide the support for RSC, which I think is a bigger deal. For now I can get Material You components by theme customization.

sorry to asking here, but how do you get the  Material You in v5? can you share the theme customization?

My vote is option 3 so we can get a styling solution fully compatible with Next.js's App Router and RSC as soon as possible, unless we think Next.js and React will figure soon how to make CSS-In-JS work with RSC (doubtful).

It took me a while to figure out what the three offerings were, so I've re-worded them, below, in a way I hope is simpler:
I believe Marija was asking whether people prefer:

MUI v6 to include Material 3/You plus React Server Components and other code improvements (mentioned at the end of this comment, possibly as an opt-in)
MUI v6 to include only Material 3/You (MUI v7 to include the React Server Components and other code improvements).
MUI v6 to include only the React Server Components and other code improvements (MUI v7 to include Material 3/You).

(I hope it got it right. Please delete this comment if it's not accurate.)
Without knowing how long option 2 and option 3 are estimated to take, or whether the RSC and other changes would cause difficult migration or breaking changes between MUI 6 and MUI 7, it's difficult to vote with confidence. Option 1 seems like the safest option even though it is slowest, as all dependencies will be figured out before release.

+1 for option 1 :)

There is already a lot on the mui v6 wishlist as of today and I assume it will take some time to do all of those things or at least most of them, so to me it would be good to make a v6 release without material you first to get all those things out asap, the most important thing to me is that mui works perfectly with server components, I see every major react framework now adopting them, if mui is slow on transitioning to staticly generated css then users might switch to other UI packages that do (chakra (panda css), tailwind ui, ...)
then after the new styling system is in place, "material you" could get implemented, seond argument is that I'm also very interested in seeing where joy goes and might actually use joy and not material you / material ui for future projects if joy supports all the components that mui does, I say this because I mostly work on mobile apps using capacitor and don't want my apps to look like android apps on iOS, I want something like joy that is more "neutral" and that I customize a lot myself
this is why I chose 3

My vote would be for 1 or 3.  I think having Material You opt-in (if it's included) is a good way to ease folks into it.  3 is attractive if it'll take a significant amount of additional time to achieve 1, for similar reasons that @chrisweb articulated.  I'm not particularly interested in the Joy side of things, but getting ESM support for me is extremely important, and if achieving #1 significantly delays that, then I'd rather have it without the initial Material You support.

Hey Everyone! I’m happy to share that the work toward adopting Material You has started and we’re looking for contributors to help us 🚀
In the description of this issue, you will find a contributing guide on how to migrate a component to implement Material You specs, as well as a list of the components and their migration status. This issue will act as the umbrella issue for this effort.
If you have any questions, feel free to reach out 😊.

Very excited about this.
Love the chip playground ❤
Is there a dedicated playground for every component? Or perhaps a subdomain (previously next.mui.com), where I can see a dedicated page for MUI 6 components?
I'm in the process of adapting MUI 5 to adhere to the design specs of Material 3 right now

@NawarA Currently, there is no dedicated page for the components. If we do that in the future, we will announce it here.
With each component we migrate, we will add a playground. I added the link to each component's playground in the progress section of this issue's description.

I'm in the process of adapting MUI 5 to adhere to the design specs of Material 3 right now

Are you doing this for a specific project?

Yeah, doing it for Bytez.com.
My first project that used MUI 5 adapted to Material 3 was Seed Swipe, an internal tool I built (Tinder for Investors) I used to meet/match with hundreds of investors. My current project is Bytez.com, where we'll adopt the tokenization and theming to the specs of the handful of components described in the Material 3 standards.
I'd 100% share my work, but not sure the easiest way to do that.
The most important thing, in my opinion, is the MUI 6 has an easy way to generate a theme with primary, secondary, tertiary colors, and the theme has built in tokenization for type-scale, [shapes] (https://m3.material.io/styles/shape/shape-scale-tokens), elevation, and colors.
Once you have a theme that has these CSS rules built in, then its all about using Box components or Sx to apply them to create cards, chips, or whatever the component the spec describes.
So to me, the theme is the foundation, and then it makes it really easy to build any component.
Happy to share my work as I go along. Do we have a Material 6 theme generator?
If not, I think that could serve as the foundation of all work.

@NawarA I would love to see it

As a note for anyone who still needs a current Material 3 implementation for React and cant wait for MUI to update, https://konstaui.com/ has implemented a full set of Material 3 components.

@pramod-tardigrade It generates material 3 colors based off a provided color, as follows:
https://konstaui.com/react/colors
Then it exposes those as tailwind config colors, so you can use them in tailwind classes like 'bg-primary'. If you want to access, the colors directly- tailwind.config is just a json file, so access the desired field under theme.extend.colors after importing the JSON.

Hey everyone! You might have seen the announcement about Material UI 2024 releases.
I wanted to reassure everyone interested in Material 3 that we're not delaying this work: it was always planned for a late 2024 stable release. We're just adding a major release in between as we think that will be a smoother update experience.
You'll continue to have access to the Material 3 components via the material-next package. We also hope the ongoing contributions to this effort continue.
I'll move this issue and related ones into the Material UI v7 milestone.

Hey @pramod-knidal, we're working on a guide on this, but here's a sneak peak in the meantime:
Installation
npm install @mui/material-next @emotion/react @emotion/styled

(Or your preferred package manager)
After this, the steps are the same as for the @mui/material package. You should follow the Material UI installation guide from the Peer dependencies section forward.
Usage
import * as React from 'react';
import Button from '@mui/material-next/Button';
import { CssVarsProvider } from '@mui/material-next/styles';

export default function MD3ButtonUsage() {
  return (
    <CssVarsProvider>
      <Button variant="filled">Hello world</Button>
    </CssVarsProvider>
  );
}

(Here's this example as a CodeSandbox)
I hope this helps and that your project goes well. Any feedback, or even better, contributions, for the Material 3 components will be greatly appreciated 😊.
The detailed version of this guide should be released soon. I'll post it here when that happens.

If we want to use a custom color to generate the m3 color palette and use that, how is that done?

:warning: We just merged a change on how to do this, so the following example will be available from the next release, which should be<EMAIL_ADDRESS>next week.
import { extendTheme, CssVarsProvider } from '@mui/material-next/styles';

const customTheme = extendTheme({
  ref: {
    palette: {
      primary: {
        0: '#000000',
        10: '#002020',
        20: '#003738',
        30: '#004F51',
        40: '#00696B',
        50: '#008587',
        60: '#00A1A3',
        70: '#00BEC1',
        80: '#2DDBDE',
        90: '#8FF3F4',
        95: '#B2FEFF',
        99: '#F1FFFF',
        100: '#FFFFFF',
      },
    },
  },
});

export default function App() {
  return (
    <CssVarsProvider theme={customTheme}>
      // ...
    </CssVarsProvider>
  );
}

You can use Material's Figma MD3 Theme Builder plugin to generate the palette tones.

I guess, what you're asking about, is whether there's a function to dynamically generate a palette from a single spot color?  That would definitely be a useful feature.

@michaelfaith they have!: https://github.com/material-foundation/material-color-utilities
If someone is interested, it would be nice to have an example of integrating those utilities with material-next. I would start by installing both packages separately and see if it's easy to wire them together on the developer's side.
@pramod-knidal for now (when<EMAIL_ADDRESS>releases), you must manually provide the palette. The theme builders export the tokens, so you should be able to copy paste (again, when the next release goes live next week).

so, how is the primary palette used? are other m3 colors (secondary, tertiary, error, background, etc.,) generated internally?

You'll need to provide the tonal palette for all color roles you'd like to customize. If you provide the primary palette, like in the example, only the primary color changes. Nothing is generated internally. I recommend checking out the material-color-utilities and see if that helps. Let us know if you do. For more information check out Material 3's color system.

Would it use to theme the components the way it is defined in m3 standard?

Exactly, the material-next theme structure follows the MD3 token structure. For example, the specs for the primary filled common button's background color is mapped as such:

This is implemented with CSS Variables in the material-next's Button component, which has:
background-color: var(--md-sys-color-primary)

And
--md-sys-color-primary: var(--md-ref-palette-primary-40, #6750a4) /* the second value is a fallback to the default theme */

So when you provide ref.palette.primary[40] to the theme, that value is used for the --md-ref-palette-primary-40 variable, replacing the color.
It's important to provide all the tones (0, 10, 20, ..., 99, 100) as those are used for other components states and modes. You can see this in more detail in the Common buttons specifications as well as the Button component's playground.

@michaelfaith they have!: https://github.com/material-foundation/material-color-utilities
If someone is interested, it would be nice to have an example of integrating those utilities with material-next. I would start by installing both packages separately and see if it's easy to wire them together on the developer's side.

Thanks!  That looks promising.  I'll check it out.

@DiegoAndai Opened issue for List https://github.com/mui/material-ui/issues/40368

I wonder if md3 styles are going to be applied and md2 styles removed in the next major version.

I wonder if md3 styles are going to be applied and md2 styles removed in the next major version.

As the 2024 release plan announcement mentions, Material 3 (MD3) is not planned for the next major version, v6, but the one after that, v7.
For people relying on Material 2 (MD2) styles: When the components with MD3 design are released, there will be a smooth transition path from MD2 to MD3. It's too early to know what that transition would look like, but it's a requirement.

For people relying on Material 2 (MD2) styles: When the components with MD3 design are released, there will be a smooth transition path from MD2 to MD3. It's too early to know what that transition would look like, but it's a requirement.

I'm worried about if md2 is removed. Our theme has modified the style a lot so it does not look like md2 (but override styles are based on md2), if we have to rewrite (or test everything) based on md3 to keep it looking the same as what we have today, it will be harder for us to migrate.

I'm worried about if md2 is removed. Our theme has modified the style a lot so it does not look like md2 (but override styles are based on md2), if we have to rewrite (or test everything) based on md3 to keep it looking the same as what we have today, it will be harder for us to migrate.

Don't worry. This exact case is what I was referring to with "there will be a smooth transition path from MD2 to MD3". Whenever I have more detail on how that transition would look like, I'll post it here. We know there are a lot of projects with customized styles over MD2, and we look to provide the best upgrade experience to those projects.

The Material 3 components guide has been released: https://mui.com/material-ui/guides/material-3-components/

I just checked out the @mui/material-next package and noticed something. the CSS tokens used don't appear to follow M3 guidelines fully. Like the tokens generated by https://material-foundation.github.io/material-theme-builder/ and https://github.com/material-foundation/material-color-utilities are completely kebab-cased (like --md-sys-color-on-primary) but @mui/material-next appear to have the last part camel-cased (like --md-sys-color-onPrimary).
Is this something overlooked or am I missing something? Just saying coz, it would be great if all the libraries using M3 followed it completely (like https://github.com/material-components/material-web) so that they could be drop-in replaced easily and not care about matching themes.

Hey @JoseVSeb. Indeed, there's inconsistency. I created an issue (https://github.com/mui/material-ui/issues/41136) to review it before the stable release. Thanks for the feedback! 😊

Will there be an ESM release?

Hey @arunmmanoharan. All of our packages support ESM, including material-next. When the Material Design 3 components are released in their stable version, they will also support ESM.
We're also working on improving the ESM support for v6: https://github.com/mui/material-ui/issues/30671

I scrolled through the comments here and didn't see anything on this - what would adopting material 3 design mean for support of material 2 in future versions of mui?

Hey @singerbj, thanks for reaching out!

what would adopting material 3 design mean for support of material 2 in future versions

It has yet to be decided. I expect to have a decision by the end of Q2 of this year.
I want to take the opportunity to ask you or anyone else interested: How do you think we should handle Material Design 2 moving forward? The community's input on this is essential.

I want to take the opportunity to ask you or anyone else interested: How do you think we should handle Material Design 2 moving forward? The community's input on this is essential.

I'd prefer separate npm packages. V2 as legacy maybe.

@DiegoAndai wasn't it already decided in this discussion thread? (link to MUI's maintainer's comment)

@o-alexandrov, thanks for linking this. Honestly, I wasn't aware of it. It has valuable insights. The community leans towards separate packages and smaller bundle sizes. Having a legacy Material Design 2 package makes sense as an option.

@o-alexandrov, thanks for linking this. Honestly, I wasn't aware of it. It has valuable insights. The community leans towards separate packages and smaller bundle sizes. Having a legacy Material Design 2 package makes sense as an option.

This makes sense to me and will be relatively easy to adapt our company's design system to use the MD2 packages if we need them.
As Material Design goes through its versions in the future, Is there any direction on whether old versions of the design that are made into legacy packages will become deprecated? Are users expected to be on the latest version of the designs to ensure they are getting the proper security/accessibility/defect fixes/updates? Or will all design versions be maintained going forward?

Basically I am wondering if my company needs to plan to switch to material design 3 components at some point in the future.

My answer would be essentially the same: It still needs to be decided. The "legacy" package is an option, but I don't know whether that package would be maintained or deprecated and eventually removed. I can say that we want to provide the best experience for current users so they can continue shipping their apps with as little friction as possible.
Your feedback (and anyone in a similar situation) is key to coming up with the best solution. If you could answer these questions, that would be great:

How did you customize the components?
How much customization does your app have? Is it closer to a custom design system, or is it closer to a Material Design 2 look?
If it's closer or exactly a Material Design 2 look, are you (or your team) okay with it? Or do you have plans to move to a custom look? Or moving away from Material Design?
What are your (or your team's) opinions on Material Design 3? Would you like or be willing to adopt it?

Feel free to reply in a comment. If anyone is willing, we can also schedule a call to discuss these questions. If you're interested, please reach out to<EMAIL_ADDRESS>This would be very helpful in determining the best path forward.
I'm sorry I don't have any more information at the moment. We're working on getting v6 ready, but soon, we will begin planning v7 and how to deal with Material Design's different versions.

Makes sense! Just want to get as much information as possible. It still feels "early" to me, but I will note down your email in case we do wish to reach out directly! Thanks!
Here's some answers to your questions:
#How did you customize the components?
We don't have many customizations at all actually, we mainly "forward" the components on in our own package. We set it up this way with the idea that if we did want to customize anything, we could. One thing we did do was limit the exposure of the documentation of props for each component to ensure that devs use the components properly - but thats more of a docs thing that a component thing.
#How much customization does your app have? Is it closer to a custom design system, or is it closer to a Material Design 2 look?
It is almost exactly a MD2 look with some minor modifications basically all modified via a theme.
#If it's closer or exactly a Material Design 2 look, are you (or your team) okay with it? Or do you have plans to move to a custom look? Or moving away from Material Design?
#What are your (or your team's) opinions on Material Design 3? Would you like or be willing to adopt it?
Not sure on either of these yet. We as the "UX Dev Team" focus mainly on maintaining our library and design system docs and are guided by our UX design team on decisions like this. A big change might be detrimental to our company efforts of UX alignment, but I could also see our design team not wanting to get stuck in the past. There are some complexities too, one being that we recently introduced a complimentary angular library based on angular-material. I will have to discuss further with our greater UX team - I planned to anyway, I just happened to start here to gather information :)

Hey, @fiorins! Yes, sorry for the inconvenience. The guide has been pulled down while we determine the best approach for delivering the Material 3 components in a backward-compatible way. We should have updates on this by June. It will take until June because right now we're focusing on the development of v6. But I'll comment on this issue as soon as possible.

Not sure, if it's helpful to mention, but I overhauled our MUI5 to Material 3 manually.
I did it by

Creating a MUI 3 theme, and copying the palette into my theme.js file, which also imports Roboto-Flex, and sets up the MUI 3 typography variants (headline, display, title, body, label, etc), sets up the correct "shapes" (for border radiuses) and "motion" (for transitions).
I created each component by following the MUI 3 specs.
I used Box a lot, lol

The key is the theme is comprehensive, and your MUI 3 Component specs follow 1-to-1 with the MUI 3 specs. I also have a dark theme, which looks dope, but I dont currently have enabled on my site.
Here's my site for reference on MUI 5 easily migrated to MUI 3:
https://bytez.com/

Lots of comments here about what kind of traction M3 will get if any, so I'd like to just jump in, and let folks know that my own team/peers are exclusively M3 now, and have been for a few years.
It's pretty important for us, that native and mui screens look at least somewhat similar.

Not sure, if it's helpful to mention, but I overhauled our MUI5 to Material 3 manually.
I did it by

Creating a MUI 3 theme, and copying the palette into my theme.js file, which also imports Roboto-Flex, and sets up the MUI 3 typography variants (headline, display, title, body, label, etc), sets up the correct "shapes" (for border radiuses) and "motion" (for transitions).
I created each component by following the MUI 3 specs.
I used Box a lot, lol

The key is the theme is comprehensive, and your MUI 3 Component specs follow 1-to-1 with the MUI 3 specs. I also have a dark theme, which looks dope, but I dont currently have enabled on my site.
Here's my site for reference on MUI 5 easily migrated to MUI 3:
https://bytez.com/

Can you share those components?

Not sure, if it's helpful to mention, but I overhauled our MUI5 to Material 3 manually.
I did it by

Creating a MUI 3 theme, and copying the palette into my theme.js file, which also imports Roboto-Flex, and sets up the MUI 3 typography variants (headline, display, title, body, label, etc), sets up the correct "shapes" (for border radiuses) and "motion" (for transitions).
I created each component by following the MUI 3 specs.
I used Box a lot, lol

The key is the theme is comprehensive, and your MUI 3 Component specs follow 1-to-1 with the MUI 3 specs. I also have a dark theme, which looks dope, but I dont currently have enabled on my site.
Here's my site for reference on MUI 5 easily migrated to MUI 3:
https://bytez.com/

Can you share those components?

let me know which components you want, and i'll drop the Box + styling for those

Not sure, if it's helpful to mention, but I overhauled our MUI5 to Material 3 manually.
I did it by

Creating a MUI 3 theme, and copying the palette into my theme.js file, which also imports Roboto-Flex, and sets up the MUI 3 typography variants (headline, display, title, body, label, etc), sets up the correct "shapes" (for border radiuses) and "motion" (for transitions).
I created each component by following the MUI 3 specs.
I used Box a lot, lol

The key is the theme is comprehensive, and your MUI 3 Component specs follow 1-to-1 with the MUI 3 specs. I also have a dark theme, which looks dope, but I dont currently have enabled on my site.
Here's my site for reference on MUI 5 easily migrated to MUI 3:
https://bytez.com/

Can you share those components?

let me know which components you want, and i'll drop the Box + styling for those

Thank you so much! I really liked the navbar (both mobile and web versions), as well as the animation in the search bar. What impressed me the most was the bottom sheet in the chatbot!

We've built a component library for React which implement Material 3.
It also has additional components like Typography, Box etc with an API very similar to MUI, so it's relatively easy to migrate.
Would love to get this thread's feedback on it:
https://material-web-components-react.grayhat.studio

i'm also trying to create my own M3 customization on mui, i'm using only createTheme customization for compatibility issues, but welp, still on development on other components so the code maybe isn't written so well.
here's demo
https://material-ui-theme-teal.vercel.app
and here's my repo
https://github.com/BanDroid/material-ui-ts-theme

Is there an official timeline from MUI on when material 3 will be generally available? I see it's currently slated for 7.x but is that confirmed? Is there a timeline? Thanks!

any updates?

Hey everyone! Sorry for the delay.
In December 2023, we announced that we'd begin working on MD3 implementation after releasing Material UI v6. V6 was released last month, so the MD3 project is now underway.
As to why the version milestones and labels were changed: we didn't mean to change them so soon. We're still in the process of revising our internal and public roadmaps as we reevaluate the needs of the community post-v6.
We're also preparing an official announcement with complete details about what's next, so please stay tuned for more soon.

We're also preparing an official announcement with complete details about what's next, so please stay tuned for more soon.

Do you have an estimate for the official announcement release?

@TheOneTheOnlyJJ estimated time is around the beginning of December.

Hi team, I would love to contribute here, let me know the pending items to start with.

Hey everyone,
Thanks for your patience. We just published the 2024 review blog, briefly reviewing what this year has been: https://mui.com/blog/material-ui-2024-updates/.
In it, we cover Material Design 3. The bottom line is that, sadly, we won't deliver MD3 this year, as we previously thought. It won't happen in the first half of 2025, either. The main reason is that in the second half of this year, the team has focused on supporting the v6 migration and support for the React 19 release.
I'm sorry to have everyone waiting for so long. I'm also personally regretful of having promised dates without delivering. I understand this can be frustrating. With 2024's priorities now completed, this is a top priority. We're already working on it and will update you as soon as we have any information.
I hope you stay tuned. I appreciate your patience. I'm excited about what 2025 will bring. I hope you're too.
As always, feel free to reach out. From the Material UI team, we wish you great end-of-year celebrations 💙.

Hi @DiegoAndai,
Thank you for the update. However, I noticed a discrepancy in your statements.
In this update, you mentioned there won’t be any news regarding M3 in the first half of the year. However, in your blog, it was stated that an update for M3 is expected in the first half of 2025.

This is a bit confusing. First, there was the issue with the false date promise, and now there are two conflicting statements.
Could you please clarify if we can actually expect any updates on M3 in the first half of 2025?
Looking forward to your response.
Best regards,
Sharad

[like]  Krzysztof Nikiforuk reacted to your message:

From: Sharad Soni @.>
Sent: Wednesday, December 18, 2024 5:18:00 AM
To: mui/material-ui @.>
Cc: Krzysztof Nikiforuk @.>; Manual @.>
Subject: Re: [mui/material-ui] Adopt Material Design 3 / Material You (Issue #29345)
⚠ This email originates from outside the organization or the sender could not be verified.
Hi @DiegoAndaihttps://github.com/DiegoAndai,
Thank you for the update. However, I noticed a discrepancy in your statements.
In this update, you mentioned there won’t be any news regarding M3 in the first half of the year. However, in your blog, it was stated that an update for M3 is expected in the first half of 2025.
image.png (view on web)https://github.com/user-attachments/assets/859a3b21-e995-4902-a9ad-fa1b8c4fbb7a
This is a bit confusing. First, there was the issue with the false date promise, and now there are two conflicting statements.
Could you please clarify if we can actually expect any updates on M3 in the first half of 2025?
Looking forward to your response.
Best regards,
Sharad
—
Reply to this email directly, view it on GitHubhttps://github.com/mui/material-ui/issues/29345#issuecomment-2550359404, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BATBS6A7KEKWY5DRFB2DR5D2GEAQRAVCNFSM5G3MCLTKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENJVGAZTKOJUGA2A.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
Please consider the environment before printing this e-mail.

This e-mail (including any attachments) is intended solely for the use of the individual or entity to which it is addressed and may contain confidential information. This message is not a binding agreement and does not conclude an agreement without the express confirmation of the sender’s superior or a director of the company.
If you are not the intended recipient, you should immediately notify the sender and delete the message along all the attachments. Any disclosure, copying, distribution or any other action is prohibited and may be illegal. No e-mail transmission can be guaranteed to be 100% secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Although Unravel has taken precautions to ensure that this e-mail is free from viruses, the company does not accept liability for any errors or omissions in the content of this message, which arise as a result of the e-mail transmission. This e-mail is deemed to be professional in nature. Unravel does not permit the employees to send emails which contravene provisions of the law.


Let nitro ssh open straight into matching mounted directory

Is there any way that when running the nitro ssh command from a local site folder, it can detect if there is a matching mounted folder, and then drop you straight into that working directory?
Eg, if my mount config looks like this:
mounts:
- source: ~/Sites/my-website
  dest: /home/ubuntu/sites/my-website

then it would behave like this, noting the paths:
michael@local-machine:~/Sites/my-website$ nitro ssh
...
Welcome to Ubuntu 20.04...
ubuntu@nitro-dev:/home/ubuntu/sites/my-website$

It's a little thing, but would make it a lot easier for connecting from within your project in your IDE, and running things like composer update without having to cd into directories every time..

@michaelroper I really like this idea! Ideally when we consider adding craft specific commands like nitro craft update it would also need to detect the current working directory and map into a vm directory.
Right now for ssh we are running multipass shell which does not have support for arguments like the directory name but I will add an issue to discuss with that team.
Going to keep this open to track if that becomes an option down the line.

Hmm, those commands don't use multipass shell so we could consider adding those sooner than the ssh implementation.
Might be worth another feature request since the implementation is different underneath if you are up for adding another issue?

So we can achieve this with the following commands:

Navigate directly to a sites directory - nitro ssh when in a directory
multipass exec nitro-dev -- bash -c 'cd sites/site-name && bash'

Run composer update on a project - nitro composer update when in a project directory
multipass exec nitro-dev -- bash -c 'cd sites/site-name && composer update'

Closing this out in favor of #167.


[Android] Webview becoming blank when scrolling

First of all big thank for the lib.
I had the issue with the  chrome update So I updated my as suggested:
<View style={{overflow: 'hidden', flex: 1}}>
   <webview source={{ html }} style={{ flex:1, opacity: 0.99}} />
</view>

Since the release, I had some report saying that when scrolling the webview, it is becoming blank. I could not reproduced the error, I am still gathering infos.
Anyone has any idea on what is happening here?
In the meantime, I might not use JS and use this lib: https://github.com/jsdf/react-native-htmlview

Chrome has been fixed so you should not worry about this anymore :)


Edit credentials

In asset details have a new button "Manage" or  "Edit Advanced Settings" ( other naming suggestions appreciated) . If this section will be displayed or not will be controlled by a env variable.

In this section we need to add/update/delete allowList and denyList defined here https://github.com/oceanprotocol/ocean.js/pull/787
In this section we will also edit  isOrderDisabled (not part of this issue, just for context).

@mihaisc, do you have UI design for allowList and denyList?
My understanding we need to have some input field that can dynamically add or remove the credential value like wallet address and credential type.

We need to have something like below in V2 for both allow and deny list together with Credential type option.

My understanding we need to have some input field that can dynamically add or remove the credential value like wallet address and credential type.

Correct.


Tests Failing on OS X: Unable to download nodewebkit

Fatal error: Unable to download nodewebkit.

Not sure if I'm doing something wrong or if this is a real issue. I ran npm run deps before running npm test. I'm on OS X 10.9.5.

I'm getting the same issue on Linux 64 (Ubuntu 14.04).
git clone https://github.com/edjafarov/node-webkit-updater.git
cd node-webkit-updater/
npm install
npm test

Same on windows 7 64.
My initial hunch is that it's related to dl.node-webkit.org being redirected to dl.nwjs.io. This is handled by the node-webkit-builder module. Version 0.2.2 is used here, most recent is 1.2.0.
if your platform is in here there's a good chance that just upgrading to the latest node-webkit-builder will solve the issue.

I confirm, updating to a newer version of grunt-node-webkit-builder solves this, see this commit.
That said, on mac & windows it's still not perfect because the latest versions of nwjs include 32 & 64 bit versions for those platforms, whereas the current node-webkit-updater test code isn't meant for that. Are there any plans regarding this? @adam-lynch ?

As far as I know, there isn't much that would need to change (if anything) to support 32 and 64-bit. Right?

I don't think so, no. I could probably patch & PR it if that's something you guys want to have part of the updater. It would definitely make sense.

Turns out it's not that trivial, the updater code is affected as well. Here's my work so far, it seems to work fairly well.
The tests run up to the opened and updated log, but the test don't end and the app doesn't close itself.
Inspecting the app itself, it displays a copying app message and the console chokes on the following error: Uncaught TypeError: Incorrect value of args option in a child process. Indeed, the logged args are empty.
I'd really appreciate some insight from someones who's more familiar with the code base & maybe ran the tests before:

what is the expected behavior?
The test is waiting for something from express to complete itself but I fail to understand what exactly.
At that point, why is the app still trying to install something? AFAIK it's already updated & installed. Is that code broken?

Thanks :-)

@edjafarov or @adam-lynch ? Any ideas?

@y-lohse - I grabbed your work so far. Works a peach on windows versions. Of course you get that "copying app" issue but as long as you hide it, the user for now won't notice, as app is correct. Then the next time they load the app it is updated anyway.
However I notice the mac version fails still unfortunately, object undefined on line 157 of updater.js

Any update on this one?

same issue here


Redirect main pages directly instead of via search

Per my suggestion in Issue #324, the Main Page of the Fandom/Fextralife wiki always redirects to the Main Page of the destination wiki. However, it is currently doing this via the search URL instead of a direct page link. Since the Main Page is definitely known to exist at that title, there shouldn't be any need to go via the search URL (unlike other pages, where it is unknown if the proposed target title exactly matches).
While MediaWiki is capable of just redirecting searches to the correct page when using the search URL, DokuWiki is not. For example, when Indie Wiki Buddy attempts to redirect from the Severance Fandom Wiki's Main Page to the independent wiki's Main Page (which is run on DokuWiki), you land on this search page. The Main Page is one of the options listed there (under the display name "Welcome"), but I don't think this is immediately obvious. It would greatly improve the user experience to just send the user directly to the Main Page.
Also, in search engines, if the link is changed to be a direct link instead of a search link, I think it would be better to have a slightly different redirection notice to "Look up [MAIN PAGE TITLE] on [WIKI NAME]". My suggestion is "Go to the Main Page of [WIKI NAME]", or maybe even just the generic "Visit [WIKI NAME] instead" that's used for non-mainspace pages.

Great suggestions, thanks! It's a shame that DokuWiki's search endpoint doesn't directly take users to the page if it exists. On a tangent, I found some discussion about it on the DokuWiki forums.
I've pushed a commit with the following:

When IWB finds a main page for a DokuWiki wiki, the destination article title is set to an empty string. A search for empty string on DokuWiki will fortunately take the user right to the main page.

The reason I'm not directing the user to the barebone wiki URL is because some wikis (like YumeWiki) have multiple homepages that depend on the destination_content_prefix.

Search engine button text for main pages has been updated per your suggestion:

Changes now available in v3.4.0, now available for both Chrome + Firefox.


SAML configuration not working.

Hi,
we are using centrify as saml provider, but federated template is failing with below error.
i am giving AD FS Hostname: https://XXXXXXX-dev.my.centrify.com
2019-05-17T19:06:39.399Z e8f9cc5c-722d-4784-9f01-76d84d63ccdd Failed to create data lake Cognito identity provider:
InvalidParameterException: Non-ok status code 404 returned from remote metadata source https://XXXXXXX-dev.my.centrify.com/FederationMetadata/2007-06/FederationMetadata.xml
2019-05-17T19:06:39.399Z e8f9cc5c-722d-4784-9f01-76d84d63ccdd RESPONSE BODY:
{ "Status": "FAILED", "Reason": "https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#logEventViewer:group=/aws/lambda/data-lake-helper;stream=2019/05/17/[$LATEST]67c0ab46e276450da7462b28a9dfa0a7", "PhysicalResourceId": "FederateLogin", "StackId": "arn:aws:cloudformation:us-east-1:006976719545:stack/abc-datalake-federated-template/bf89dfa0-78d2-11e9-a00d-0a5c603a1bba", "RequestId": "8ffe0c4b-4e1e-4e58-9395-c89dab7a7305", "LogicalResourceId": "FederateLogin", "Data": { "Error": "Failed to create data lake Cognito identity provider" }
I know this url doesnot exists,
https://XXXXXXX-dev.my.centrify.com/FederationMetadata/2007-06/FederationMetadata.xml
but i dont think centrify works like MS ADFS,
May be i am setting up something wrong.

Hi,
It is working, i need to give saml metadata file in
ProviderDetails: {
'MetadataFile': ``
}
in cognito-helper.js.
After that it is working.


AWS::SSO::PermissionSet Transform  fails with !FindInMap

@benkehoe not sure if I am using it incorrectly but for permissionset the using !FindInMap fails. It works without Transform: AWS-SSO-Util-2020-11-08 to confirm the PermissionSet resource creation works otherwise
ReadOnlyPermissionSet:
    Type: AWS::SSO::PermissionSet
    Properties:
      InstanceArn: !Ref SSOInstanceArn
      Name: ReadOnly
      Description: ReadOnly
      InlinePolicy:
        Version: 2012-10-17
        Statement:
          - Sid: ReadOnly
            Effect: Allow
            Resource: '*'
            Action: !FindInMap [ CommonPermissions, ReadOnly, List ]

If I manually replace FindInMap with the list of of string that it references, the template works with the transform.
ReadOnlyPermissionSet:
    Type: AWS::SSO::PermissionSet
    Properties:
      InstanceArn: !Ref SSOInstanceArn
      Name: ReadOnly
      Description: ReadOnly
      InlinePolicy:
        Version: 2012-10-17
        Statement:
          - Sid: ReadOnly
            Effect: Allow
            Resource: '*'
            Action:
              - acm:DescribeCertificate
              - acm:GetCertificate
              - acm:ListCertificates
              - acm:ListTagsForCertificate

The error that the cloudformation console displays
Resource handler returned message: "Invalid PermissionsPolicy Document {"Version": "2012-10-17", "Statement": [{"Sid": "ReadOnly", "Effect": "Allow", "Resource": "*", "Action": {"Fn::FindInMap": ["CommonPermissions", "ReadOnly", "List"]}}]}. (Service: SsoAdmin, Status Code: 400, Request ID: 41543aa6-75d0-467b-855a-60b3e63543e9, Extended Request ID: null)" (RequestToken: 908414f0-342e-2699-4afa-5da9906b8739, HandlerErrorCode: InvalidRequest)

I'm not sure why that's happening. Along with #12, the macro isn't handling CloudFormation intrinsic functions correctly in all cases.


Pin jumps position when selected for drag (Android)

I have Version 3.2.0 from Nuget.  Android 9.0 - API 28
Here is the pin.  The icon is 90px by 90px and in the Assets directory.
_cloud = new Pin()
{
Type = PinType.Place,
Icon = BitmapDescriptorFactory.FromBundle("cloud_icon.png"),
Label = "Cloud",
IsDraggable = true,
Anchor = new Point(0.5, 0.5)
};
I set the position of the pin to the device location.
It appears in the middle of the map perfectly.

Then I hold to start drag and the pin jumps position.  Continues to be in this position for all of drag.

It is like the anchor gets reset.

pin at initial position 37.4219983333333,-122.084
pin at drag start 37.447384065051,-122.0873304829

This is specified behavior of Google Maps SDK for Android.
I think it is pin escapes from finger for drag and drop.

What do I do about it?  Is there a workaround?
Linda Rawson
ᐧ
On Sat, Jun 15, 2019 at 5:00 AM amay077<EMAIL_ADDRESS>wrote:

This is specified behavior of Google Maps SDK for Android.
I think it is pin escapes from finger for drag and drop.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/amay077/Xamarin.Forms.GoogleMaps/issues/632?email_source=notifications&email_token=AMCTXTDLSY6P2GWYL3BOCQDP2TDU7A5CNFSM4HYJZ6R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXYVXBA#issuecomment-502356868,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMCTXTF47UU2P4CDYOZBRETP2TDU7ANCNFSM4HYJZ6RQ
.

Here is the bug on google.  https://issuetracker.google.com/issues/35824023

I think it is not a bug.
I agree to comment #6.
But I can consider how to inject pin position when marker drag starting according to comment #16.

That would be great!

BTW.  You are awesome.  You have done a great job with this library.

Hi @linda-dge , How about iOS side? You feel "no problem" ?

I have not tried the iOS side.  I am trying to get my application to work
completely in Android and then work through the problems in iOS.
Linda Rawson
ᐧ
On Mon, Jun 24, 2019 at 8:33 AM amay077<EMAIL_ADDRESS>wrote:

Hi @linda-dge https://github.com/linda-dge , How about iOS side? You
feel "no problem" ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/amay077/Xamarin.Forms.GoogleMaps/issues/632?email_source=notifications&email_token=AMCTXTHYK2JSJJVAHBDNDDDP4DLJ5A5CNFSM4HYJZ6R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYND5WI#issuecomment-505036505,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMCTXTEKJ4KYQXXHYYVZCB3P4DLJ5ANCNFSM4HYJZ6RQ
.

This is iOS side's default behavior.

Long tap Pin
Pan to bottom automatically
Drag to move pin position
Release finder
Pan to up automatically

Do you feel it?
I can't disable pan automatically, also can't get pan distance.

Do you agree they both are terrible?
We probably just have to deal with it.
Linda Rawson
ᐧ
On Mon, Jun 24, 2019 at 8:42 AM amay077<EMAIL_ADDRESS>wrote:

[image: Untitled7]
https://user-images.githubusercontent.com/401369/60027761-0526a880-96d9-11e9-990c-2235e5b5fc7d.gif
This is iOS side's default behavior.

Long tap Pin
Pan to bottom automatically
Drag to move pin position
Release finder
Pan to up automatically

Do you feel it?
I can't disable pan automatically, also can't get pan distance.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/amay077/Xamarin.Forms.GoogleMaps/issues/632?email_source=notifications&email_token=AMCTXTDC3YMRHYL4O4DUUUDP4DMMPA5CNFSM4HYJZ6R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYNE5IA#issuecomment-505040544,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMCTXTEZ26XRTPHMOHBPRH3P4DMMPANCNFSM4HYJZ6RQ
.

Do you agree they both are terrible?

No, I think that it is not that big of a deal.
But I can provide some solutions.
For that you should write little tricky code.

You are the greatest.
Linda Rawson
ᐧ
On Mon, Jun 24, 2019 at 8:55 AM amay077<EMAIL_ADDRESS>wrote:

Do you agree they both are terrible?
No, I think that it is not that big of a deal.
But I can provide some solutions.
For that you should write little tricky code.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/amay077/Xamarin.Forms.GoogleMaps/issues/632?email_source=notifications&email_token=AMCTXTE3O2APANYES3ZR63TP4DN5DA5CNFSM4HYJZ6R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYNGK5A#issuecomment-505046388,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMCTXTEO5WUAINMGAQQ3Z2DP4DN5DANCNFSM4HYJZ6RQ
.

Hi. Also have this problem. For mapzoom = 15, My fix code in pindragstart\end\dragging is
            int m = map.Pins.IndexOf(e.Pin);             var l = map.Pins.Where(t => t.Label == e.Pin.Label).SingleOrDefault();             var p = new Xamarin.Forms.GoogleMaps.Position(e.Pin.Position.Latitude - (0.001347153801 * 0.5), e.Pin.Position.Longitude);
I try calculate this for other zoom, but still failed.
do you have solution for this?


Do not show Save & Continue as a floating button in the VBA flow, only show it at the bottom of each step

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Problem
As a result of https://github.com/Expensify/App/issues/5182 , the Save & Continue button will be "active" at all times in the VBA flow, meaning a user can tap/click it at any time regardless of whether all required fields are complete. This means a user might think a step ends prematurely if they are seeing a floating button that can be tapped at any time to move forward. This will lead to unnecessary failures, where a user simply wasn't aware that there were more required fields below an additional scroll.
Action Performed:

Create Workspace
Select Get Started
Choose Connect Manually option to add bank account via routing/account number, continue
See the Save & Continue option regardless of scroll position on the Company Information step

Solution
Do not show Save & Continue as a floating button, and only show it at the bottom of each step in the VBA flow. This will prevent any confusion with the newly enabled Save & Continue button as a result of https://github.com/Expensify/App/issues/5182
Notes/Photos/Videos:
Note that Save & Continue exists on my screen while I am not scrolled all the way down in this step and other fields exist below the fold.

Slack conversation: link
View all open jobs on GitHub

Triggered auto assignment to @stephanieelliott (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

Proposed Solution
We have to move Button component from FixedFooter to ScrollView i.e. before line 355 and remove empty FixedFooter component. Similar process we have follow other page also if need. Thanks.
https://github.com/Expensify/App/blob/01f351c41f59c1c991d068dd0cecca2e34f17d11/src/pages/ReimbursementAccount/CompanyStep.js#L355-L365

Triggered auto assignment to @roryabraham (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

Looks good, left as a daily since it's on the N6 milestone.

@PrashantMangukiya your proposal looks good. @stephanieelliott please hire @PrashantMangukiya on Upwork, and @PrashantMangukiya feel free to submit a pull request when ready.

Hi @roryabraham,  thank you for the message.
At present I suggested solution by analysing source code file. To prepare pull request I will prefer to test VBA steps within contributor account, but I am wandering that within my contributor account I can not see VBA flow related step.
I created workspace, also added private domain email as secondary login and verified it. Although I am not able to see Add Bank Account related flow. It shows only paypal.me method.
Any suggestion how to activate VBA flow as contributor to reproduce this issue and testing before creating pr.
Below is screenshot how my workspace looks:

@PrashantMangukiya Try going to http://localhost:8080/bank-account/new

@roryabraham Thank you very much. I can see Add Bank Account step now. Also Connect manually shows Add Bank account steps.
Attaching screenshots just to confirm that I am in right direction. Thank you again.

Hi @roryabraham, Sorry to ask many question, I am adding bank account for testing purpose, but it is not allowing to create. Is there any specific Routing and Account Number I suppose to enter in this field.

@PrashantMangukiya I don't think you'll actually need to fill out the form. There is an issue open to ensure that users can't link to VBA steps they can't complete, but it's not yet been implemented. This is good news for you, because it means that you can link directly to each individual step:

http://localhost:8080/bank-account/new
http://localhost:8080/bank-account/company
http://localhost:8080/bank-account/personal-information
http://localhost:8080/bank-account/contract
http://localhost:8080/bank-account/validate

@roryabraham  ok I got it. I will open given url and correct button layout. I think it will works to solve this issue. Thanks.

@roryabraham, Corrected floating button within VBA flow, not button shows at the bottom of each step.
I was not able to open this http://localhost:8080/bank-account/personal-information, So within ReimbursementAccount folder I check all files and corrected button wherever it was.
Corrected button within below js file.
src/pages/ReimbursementAccount/BankAccountStep.js
src/pages/ReimbursementAccount/BeneficialOwnersStep.js
src/pages/ReimbursementAccount/CompanyStep.js
src/pages/ReimbursementAccount/ReimbursementAccountPage.js
src/pages/ReimbursementAccount/RequestorStep.js
src/pages/ReimbursementAccount/ValidationStep.js
As per my knowledge button updated in all page within vba flow.  If any page missing then kindly inform me, I will update it soon. I will also create pr soon, so it will give clear idea about code update.
Below screenshot shows how it looks:

Hi @stephanieelliott, Can you please create Upwork job for me as suggested in  https://github.com/Expensify/App/issues/5183#issuecomment-917092471  So I can submit proposal. I already submit pr https://github.com/Expensify/App/pull/5208 for this issue, it is in review at present.

PR in review.

Grabbing the admin side of this one since it's urgent and it's late on EST for steph.
@PrashantMangukiya I invited you to apply for the job - https://www.upwork.com/jobs/~01fe011945cf85a2ad

@kevinksullivan Thank for the invitation, I accepted and applied for the job.

hired!

@kevinksullivan Accepted the offer, thank you.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @roryabraham in version: 1.0.98-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

The fix for this was + deployed to production. cc @mountiny it seems like maybe the deploy comment for issues messed up here and skipped this guy?
Anyways, let's start the 7-day regression timer.

@roryabraham You are right, but seems like it wasn't related to the new changes but again to that weird discrepancy when Github API returned not the latest, but second latest release. Internal link here.
The comment was left for example here on issue from previous deploy 😬 I have fixed all of them to avoid confusion.

Updating the title and adding appropriate label, because of the faulty script. Although it seems it has not been exported, or we just forgot to add a label here due to urgency. We will definitely get to it after our deadline on Friday, @PrashantMangukiya please apologies for any inconveniences which could occur with this 🙌

@mountiny and @kevinksullivan  Seven day regression period over for this issue, any suggestion who will release the payment on upwork.

Payment sent and job closed!

thanks @dylanexpensify Received.


miss named function GetContainerPidByName

in code-5.5 function stopContainer
a function "GetContainerPidByName" is used, but the actual function name declared in exec.go is "getContainerPidByName" notice the first character g is in lowercase.

欢迎提PR

seems it is me misread it,


Support for react-dev tools

For development the react-dev tools are quite handy.
Seems it is not straight forward to use those in an extension.
see: https://github.com/abhijithvijayan/web-extension-starter/issues/51
How does it work for us?

This works for us:

install react-devtools globally
start react-devtools

update configs and html page. See changes in this commit: https://github.com/bitcoincoretech/lightning-browser-extension/commit/23977691ef486bac07d186370193701fa1f2d08b
open extension page. reaxt-devtool should show this now:

Challenge: do net let the debug config get into the prod build

Challenge: do net let the debug config get into the prod build

maybe having a test that checks manifest.json or having a manifest.development.json & html?

@motorina0
getting these warnings
 with https://github.com/bitcoincoretech/lightning-browser-extension/commit/23977691ef486bac07d186370193701fa1f2d08b

according to https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/content_security_policy#invalid_examples http is not supported in a FF web-extension manifest

maybe also some inspiration from the metamask extension: https://github.com/MetaMask/metamask-extension#development-builds

anybody knows what the status here is? do we still need this?

@bumi I have updated the existing solution in my repo issue to use a new plugin to use with the html plugin.
what it does it, it takes care of the injection of <script> tag needed for React DevTools in the html files generated automatically for when NOT IN NODE_ENV === production. The manifest entry could use the prefixed dev&prod` entry to only permit that script in development.
Follow https://github.com/abhijithvijayan/web-extension-starter/issues/51#issuecomment-727558039 this if you guys still need the solution for this in a clean way.
Thanks :p


Add wildcard for any number of subroutes for auth redirect urls

With the actual implementation of auth redirect url wildcards, we can set this kind of url https://domain.com/sub1/sub2//, so any pair of subroutes of https://domain.com/sub1/sub2 are valid redirect urls, but it would be nice to have a wildcard (for instance, **) to handle any number of subroutes, so we could use it like https://domain.com/sub1/sub2/**. This would englobe:

https://domain.com/sub1/sub2/*
https://domain.com/sub1/sub2/*/*
https://domain.com/sub1/sub2/*/*/*
etc.

Hope I explained myself and please, feel free to ping me in case the feature is not well explained.

Hey @dreinon,
Nice to hear from you. To make sure I'm understanding correctly would the feature request be for something like https://google.com/sub1/sub2/** and have it match https://google.com/sub1/sub2/sub3/sub4 or any other pattern of enumeration.
We actually use Go globbing under the hood for matching so you should be able to use the ** wildcard operator like:

Let me know if this covers your use case!

@j0 yeah that's the case, but somehow it didn't work for me in supabase. Could you test it in production, please?

Hey,
Tested this on a fresh supabase instance with the following settings:

and it seems to work for the following URL:

Could I trouble you to try again on your instance? Also feel free to open a support ticket at<EMAIL_ADDRESS>if there are still persistent issues

It works now! Thanks Joel 🙂