Japanese follows English.

Improvement on Sharepoint Online with PowerApps will contribute to many users as follows:

We have customized a Custom list item view / edit screen of SPO(SharePointOnline) with PowerApps.

(Normal behavior)
Clicking item of "title hyperlink" from default list view, a customized dialog window comes up front.
I change it to "edit mode" and can edit the item in the dialog window.

(To be improved)
However, when I click on the parent (list view) window behind the dialog, the dialog closes unexpectedly and the data I have edited disappear sadly without saved.
(I need to re-open the dialog and input the same data again)

(For reference)
Ref-1. In the default SPO browsing screen without customizing with PowerApps, the dialog will not close unless I press the save button or the close button,
which I think is the normal behavior.

Ref-2. We have got an answer from Microsoft premier support that the behavior above is "restriction" of the product and were proposed to post request on this board.

--
Shinya

Japanese:
PowerAppsでカスタマイズされたSharePoint Onlineフォームにて、ダイアログで入力したデータが消えてしまいます（親ウィンドウをクリックした場合）

【詳細】
PowerAppsを使用して、SPO（SharePoint Online）のカスタムリストアイテムビュー/編集画面をカスタマイズしました。
デフォルトのリストビューからタイトルハイパーリンクのアイテムをクリックすると、カスタマイズされたフォームがダイアログウィンドウで起動します。
その後編集モードに変更し、アイテムを編集できます。

しかし、親（リストビュー）ウィンドウをクリックすると、ダイアログウィンドウが閉じられ、編集データが破棄されてしまい、大変危険です。
特に入力項目が多い場合や他の資料を参照しながらの作業の場合、操作ミスを起こしやすくなります。

（ご参考）
- PowerAppsでカスタマイズを行う前のデフォルトの SPO の閲覧画面では、保存ボタンか閉じるボタンを押さないとダイアログは閉じません（正常な動作です）
- Microsoftのプレミアサポートからは上記はSharepointとAPPSの”制限事項”との回答をいただいています（本フィードバックへの投稿を推奨されています）

• Provide an out of the box facility via the web interface to allow users to make selections to modify the formatting rather than having to generate the JSON themselves.


• Allow the JSON to be specified with a file reference rather than having to put the code directly in a field. (See also user voice entry: Allow View Formatting to reference external file, https://sharepoint.uservoice.com/forums/329214-sites-and-collaboration/suggestions/35836723-allow-vi...).


• Prompt for updating view formatting JSON when someone with appropriate rights changes the display width of a field.


• Allow the Name field for a document to be formatted via view formatting and improve the formatting capabilities via column formatting (some things can be done using @currentField)


• Allow comments in JSON used for formatting (or at least provide tools to limit VS Code to allow only what SharePoint JSON formatting allows)


• Display an indicator on the list or library Settings page for each column that has column formatting set.


• Provide JSON formatting controls to modify grouping display.


• Support automatic redrawing as items update in list and library web parts.


• Add custom date formats and date parts.


• Enhance string operations.


• Support formatting of rich text.

As Microsoft increasingly supports tailored experiences, we need the ability to operate as a user with equivalent or fewer credentials, including just not being the person who added information.

For example, a site owner who made updates to a site is seeing Updated Pages (with explicit pages underneath) in the left navigation, but has no rights to remove the navigation and didn't realize that other people weren't seeing those pages.

Another case was where the SCA had no issue opening a document with embedded documents, but it would not open for site owners and contributors.

In our on-prem environment, I was able to use a test account and assign it with certain rights to verify that those users were going to get the experience I intended, and I was able to do that with a test account. In the SharePoint Online world, for an out-of-the-box solution I'd need a second licensed account for testing in production.

Checking permissions to a site, list, library or item helps, but just isn't enough for testing the experience on a page in or in a solution.

A potential way to implement this would be to allow me to click on the name I'm logged in as, and in addition to About Me, Sign Out and Personalize this Page, have an option to impersonate a specific user (who has fewer or equivalent rights to me) or a certain level of rights (equivalent to or less than the rights I have).

Some developers in teams help test each other's solutions, changing who has what rights, but for those of us who largely work independently, we don't have that luxury.

Currently SharePoint returns https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options header when trying to embed (with <frame>, <iframe>, <object>, <embed>) documents from external websites. The header is set to "sameorigin" that simply means only pages hosted on .sharepoint.com domain can do that.

So let's see below example:
1. Company XYZ has an internal domain: xyz.com. Company is using SharePoint and stores documents e.g.: pdf's there.
2. Company XYZ has an internal technical portal: portal.xzy.com and want's to s embed documents from SharePoint.
3. Because of X-Frame-Options returned along for any pdf/doc/xls etc document #2 is impossible as web browsers will not allow to do this kind of embedding.

There are modern alternatives that can be used instead of old X-Frame-Options header.
For instance the Content-Security-Policy header, which along many other policies can white-list what URLs are allowed to host SharePoint page/resources/files in a frame, using the frame-ancestors directive. frame-ancestors supports multiple domains and even wildcards, for example:

Content-Security-Policy: frame-ancestors 'self' *.sabre.com;

The HTTP Content-Security-Policy (CSP) frame-ancestors directive specifies valid parents that may embed a page using <frame>, <iframe>, <object>, <embed>, or <applet>.

Therefore, SharePoint site administrator should have an ability to configure domains that the documents can be loaded from.