A

Anonymous

AEM 6.1 SP1 Component height not calculated correctly in edit mode touch UI

Forum|Forum|9 years ago
May 18, 2016
14 replies
15251 views

Hi,

I have component which is displayed correctly on AEM 6.1. However, when I moved it to AEM 6.1 SP1 server, it caused display problem on edit mode on touch UI. The display problem happened on Edit mode on touch UI. it is fine for the preview mode and the classic UI.

After comparing the difference between the AEM 6.1 SP1 and AEM 6.1, I noticed div and iframe height calculated from the AEM 6.1 SP1 seems wrong for this page.

In AEM 6.1 SP1 server:

while in AEM 6.1, it is

Any suggestion for fix this?

Thanks in advance.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

smacdonald2008

Level 10

what does it look like when page is rendered under /content?

A

Anonymous

The bottom part of the component does not displayed in the Touch UI Edit mode, it is cut in the middle. Also there is an inner vertical scroll bar which is not able to scroll.

D

dineshk9482940

Did you get any solution for this? we are also facing similar issue and using AEM 6.1 Service pack 1

V

vmehrotr

Adobe Employee

Please log a daycare ticket and request hotfix 9440 on 6.1 Sp1.

E

esu2805

Level 2

Hello,

Did anyone get any solution for this? I am having the same issue. And the height of iframe and ContentWrapper div keeps increasing drastically for me.

I am using AEM6.1 with sp2. I tried the hot fix 9440 too, but doesn't seem to be working. If someone got it resolved, please share.

Thanks!

acquitya8239301

We are facing the same problem since installation of SP2. We have tried CFP 1, 2 and 3 however the issue still remains unresolved. Touch UI renders only the page area visible at screen load whereas the remaining page when scrolled is rendered as Gray due to styling of overlay div height as per my understanding.

J

JeroenDruwe

Level 4

Same issue here: Adobe Experience Manager (6.1.0.SP2-CFP4) but still stops rendering. Any updates on this issue?

E

ekaggarw

Level 2

Hi,

I was also facing the same issue with AEM 6.2 in Touch UI edit mode, Height of ContentWrapper and iframe was increasing drastically throughout the site.

The reason was, we were using a css class in our base page with the below properties, which was somehow impacting the ContentWrapper class:

.wrapper {position: relative;min-height: 100%;margin: 0 auto -298px; }

here, the bottom margin was given in -ve that's why height of ContentWrapper and iframe was increasing drastically in author mode.

To fix this issue, setting the bottom margin property to positive value solved the problem as in below example:

.wrapper {position: relative;min-height: 100%;margin: 0 auto 0px; }

Note: The ContentWrapper class is only added in Touch UI edit mode that's why the issue was coming only in this mode not in classic and preview mode.

anuj_khanna_77

Level 2

Guys,

Is this a known issue and reported with AEM 6.1 SP. Can you point me to the known issues listing where this is listed.

kautuk_sahni

Community Manager

I have asked internal team to have a look at this one.

~kautuk

Kautuk Sahni

S

sumitkaila88

Hi kautuk sahni,

Although this is a very late time to response on this thread, but i assume i would still be able to find solutions to similar items.

Let me give you a brief idea to you on the issues we are facing.

We are currently upgrading from 6.2 to 6.4.

Now in 6.2 we had few components which were having floating CSS properties.

So if a floated component was dropped and after that any non-floated component was dropped, everything was working fine.

the "editable zone"(blue border) of non-floated element was overlapping the editable zone of floated component, but still they both were individually clickable.

but in 6.4 some how the floated element is not clickable and overlapped component is always in the mouse hover precedence.

We drilled down more and found that the div("data-type='Editable'") order/sequence of both components (floated followed by non-floated) is reversed in 6.4 when compared to 6.2 and since the z-index of both components is 10, it will give priority to the top level element always.

So can you suggest any work around to this of a genuine fix with which the editable zone allows the mouse hover and click events on the original component.

Regards,

Sumit

M

mickjleroy

Level 2

Running into this issue with AEM 6.2 as well.

UPDATE:

The issue is in "/libs/cq/gui/components/authoring/editors/clientlibs/core.js" the "currentHeight" is always equal to the "targetHeight" so no resizing takes place.

/** * Resets the height of the ContentWrapper and ContentFrame; used to adjust the iframe height when a change occurs inside of the content page * This is called on cq-contentframe-layout-change event * * @memberOf Granite.author.ContentFrame * @alias resetContentHeight */ self.resetContentHeight = function () { var document = self.getDocument().get(0); var getDocumentHeight = function(doc) { return Math.max(doc.body.scrollHeight, doc.documentElement.scrollHeight, doc.body.offsetHeight, doc.documentElement.offsetHeight); }; if (document) { var currentHeight = self.iframe.height(); var targetHeight = getDocumentHeight(document); // Height of the iframe content var editorHeight = $(window).height() - self.topOffset; // Height of the editor (window - toolbar) if (targetHeight < editorHeight) { targetHeight = editorHeight; } if (currentHeight !== targetHeight) { window.requestAnimationFrame(function () { self.wrapper.height(targetHeight); self.iframe.height(targetHeight); }); } } };

kautuk_sahni

Community Manager

It is a known bug, Please create a daycare ticket for this.

Some Workarounds:-

1. introduce page refresh when switching to preview, as pointed out in this blog article
2. implement at project level a new action in the page header, as mentioned in the documentation that opens the page with ?wcmmode=disabled (removing the editor.html and adding ?wcmmode=disabled works)

"View as published" feature got introduced from AEM 6.2, please re;quest for back porting.

I hope this would help.

~kautuk

Kautuk Sahni