Hi @ribafs can you please add some text which step you take so we can reproduce this? I'm not exactly sure what you mean nor how you get there, what is the expected and what is the actual result ?

You mean this dropdown?

See here:

@ribafs can't recreate Issue:

System information

4.0.0-dev
macOS Sierra, 10.12.6
Firefox 57 (64-bit)

MAMP 4.1.1

• PHP 7.0.15
• MySQLi 5.6.35

OK
Im using
Linux Mint 18.1 with Firefox 57 or Chrome 62.
PHP 7.0.22
MySQL - 5.7.20

In main menu Shop and Parks are submenu from Sample Sites but int site when move mouse over Sample Site dont display submenus but its already are displayed.

@ribafs tried to simulate the Issue but didn't understand your comment above. Can you please explain it, maybe with Screenshots or Video?

If this Issue get no Response, it will be closed at 28th February 2018.

I can confirm this issue on ubuntu without sample data with the current 4.0-dev branch.

Thanks @astridx, Issue stay open.

I can confirm the issue after installing 4.0-dev of some minutes ago. No test datas installed. "Normal provider installation." But had the issue also with older Joomla 4.0-dev with and without test datas.

PHP Built On 	Linux dd1620 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9 14:43:09 UTC 2018 x86_64
Database Version 	5.5.58-nmm1-log
Database Collation 	latin1_swedish_ci
Database Connection Collation 	utf8_general_ci
PHP Version 	7.1.11-nmm1
Web Server 	Apache
WebServer to PHP Interface 	fpm-fcgi
Joomla! Version 	Joomla! 4.0.0-dev Development [ Amani ] 19-November-2017 16:34 GMT
User Agent 	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

Also with PHP Versions
7.2
7.1.11-nmm1
7.0.25-nmm1

Firefox (ESR version), 52.6.0 (32-Bit)

Looks like that type="menuparent" in form-XML is case sensitive somehow.

Field https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_menus/Field/MenuParentField.php is not called. Tried it with a exiting debug line.

When I change line
https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_menus/forms/item.xml#L85
to

type="MenuParent"

all fine. But I don't think that this is a correct fix(?)

Linux works case sensitive concerning filenames. Mac and Win not. Ithink that's the reason why some of you couldn't confirm the issue(?)

See also related #19542 (comment)

Does anybody know if type values in xml manifests have to be camel-cased in the future (= matching file names)? See above #18633 (comment) .

If yes I could provide prs for this issue and #19542

I don't think values in XMLs should be case sensitive. Looks more like a bug to me.

I think, type="menuparent" it was not case sensitive, but after moving to name spacing it become case sensitive.
Autolader search for MenuparentField.php

maybe @laoneo have an idea

This is why we need a form registry and need to break the internal coupling toward filesystem paths or class namespaces.

This is why we need a form registry

do you mean a registry of a form components (fields, rules, etc)?
that would be cool, yes

Right, similar to https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Log/LoggerRegistry.php or https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/HTML/Registry.php

@mbabker to do this for the library should be not a hard task, but any idea how it could work for extensions?
whether something like com_foobar/form/formRegistry.json wich can be loaded by FormRegistry class, would be sufficient?

No, we should not be creating arbitrary files that get read by a magic black box. We need to be working toward a configuration over convention based system where components can be service providers, not have hardcoded inbuilt convention based dependencies (and even some of the code written new for 4.0 continues to perpetuate that problem, i.e. all the "proxy to other app" logic that the component dispatchers have to somehow be aware of). How we get there is still to be determined because we keep treating components as things that should be loaded in isolation, but we need to be working that out.

Form files are not bound to a component, we need to keep that in mind here.

Neither is the registry concept. However, it does require that SOMETHING trigger the code required to add services to the registry.

If you're familiar with Symfony bundles, or Laravel packages, that is largely what we should be aiming to have components be at a very high level. Components should not be isolated application handlers (though they do provide infrastructure to process application events, including HTTP request handling). Components should be an integration point into Joomla for defining new services and architecture (services for the container, MVC layer interactions (data schema and interaction tools, controllers to process HTTP requests, etc.), form objects into a registry, JHtml helpers, in the case of Smart Search the indexer library, etc.).

This is no longer reproducable as the type has been updated to camelcase