confirmed.
@infograf768 the one i talked about.

IMHO we shouldn't use '*' to identify the no menu item selection, just '' (empty string) like all other filters..

It used to return to
administrator/index.php?option=com_menus
and displayed the first menu alphabetically. Now it returns to
administrator/index.php?option=com_menus&view=items&menutype=
and appends a menu name only if a menu has previously been visited during that login session.

@Webdongle please test #10459

Please notice that #10459 only solves a part of this issue (the 403 error)

The other part (wrong redirect after creating a menu item i think it's another thing)

Confirmed.
The second subissue in this issue (the wrong redirect) already exists in 3.5.1.

It seems when we open the select menu type modal we lose the menutype=xxxxxx in the URL.

You check that issue with this:
1. Use 3.5.1
2. Logout from backend
3. Login in the backend
4. Go directly to the admin menu Menus -> Any Menu -> Add new menu item
5 .Notice the URL in the new/edit menu item page (&menutype=xxxxxx)
6. Now press select menu item and select one menu item type and close
7 .Notice the URL in the new/edit menu item page (no &menutype=xxxxxx)

Notice the URL is not the problem itself, the menu where we are should be saved on open the new/edit menu page. I will try to check this also.

ok second PR to solve the redirect issue #10460

Please test.

#10460 solves this issue so closed

@Webdongle #10460 doesn't solve the two issues.

Even with #10460 if you go to /administrator/index.php?option=com_menus&view=items&menutype= you get the 403 error.

Thast's why i also created #10459. Please test.

@andrepereiradasilva

Now I am lost ... administrator/index.php?option=com_menus&view=items&menutype= was the url that was reached after clicking Cancel or Close in the menu item. It was not typed in directly.

When #10460 is applied then clicking Cancel or Close in the menu item returns to administrator/index.php?option=com_menus&view=items&menutype=menuname. That fixes this issue ... the issue never occurred when the 'menu items' on the side bar had been visited. So to test #10458 prevents this error from happening even before that patch is applied because the test instructions require the 'menu items' on the side bar is visited

However #10460 can be tested without visiting the 'menu items' on the side bar and can be tested for this issue. I have tested and it fixes this issue.

#10460 fixes this issue itself, because you don't have anymore the /administrator/index.php?option=com_menus&view=items&menutype= URL directly on joomla (that i know of). In other words the problem is masked.

#10459 fixes the issue one step further by allowing to use that URL without a 403 as a fallback (in case the menu type is not found or something) to the all menu items list view.

"#10459 fixes the issue one step further by allowing to use that URL without a 403 as a fallback (in case the menu type is not found or something) to the all menu items list view"

Ah but before the issue began >>> navigating Menus ... hover over menu ... select create new menu ... then cancel or close ... never didn't look for anything in 'all menu items list view'. It just returned to administrator/index.php?option=com_menus&view=items ... it didn't look for for anything with &menutype=

This issue was about the url that the close/cancel returned to was incorrect so #10460 fixes this. _#10459 is separate because it deals with handling the wrong url not replacing it. Will test later but can't reproduce the issue following the test instructions it has.

You're right #10460 solves the issue described here.

Will test later but can't reproduce the issue following the test instructions it has.

Thanks. Updated test instructions and title to remove the link to this issue.