The issue is likely linked to the fact the editor makes use of an iframe to render the page and this must be affecting how the height is calculated, causing it to believe the height encompasses the full content of the page, not just the visible viewport. Do you have a meta tag for viewport?  setting...

Agreed - /bin and /content are accessible by default for anonymous access, but other paths would require you to force a login on the publish instance.

Another thing to try would be to run "aio app get-url" as this will list the urls the project will deploy to and "aio app info" which will dump a json version of the project setup including all the data from the manifest.yml - you can then validate it is showing the values you expect. "aio app use" ...

By default the details of successful jobs aren't kept as these don't generally give any useful information, though you can enable it if needed in the queue config.  Failed jobs are kept as this enables you to review the failure and resolve it. As you've touched on, the difference between a CANCEL an...

To make use of the standard aio endpoint authentication you would likely need to implement the full oauth token generation process in your codebase, taking your client key etc and using the token API to convert this into a token.  You could potentially cache this for a period of time to avoid every ...

are you able to share the full path of the page.js file which isn't updating?

If this is happening on a test env and not locally one area to look at would be caching as often locally you would not be going via dispatcher etc which could be caching.  You could check this on your test env by appending query string params to the file path which would bypass dispatcher cache and ...

I would recommend ensuring this is logged as a support case via https://adminconsole.adobe.com/ - if you don't  have access or you don't see the "support" option at the top, you may need to talk to an administrator of your account to find someone with the "Support Admin" role who would be able to ac...

in your example you are creating the fragment, then loading the root resource which was created and setting values on this - CF's have a much more complex internal structure as the data is not stored directly on the root resource:   You are getting a ContentFragment object back from the createFragme...

It sounds like you have quite a complex use case, so it's hard to give a definitive recommendation.  It seems unlikely that the event handlers themselves would get modified to trigger post DOM update. One potential work around might be to have the afteredit event listener add a mutation observer on ...