Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

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

Avatar

Former Community Member

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:

<div id="ContentWrapper" style="height: 662px;">
    <div id="FullScreenMask" style="display: none;"></div>
    <iframe width="100%" height="500" frameborder="0" allowfullscreen="" id="ContentFrame" src="/content/xxx/testhome.html" style="height: 662px;"></iframe>
</div>

while in AEM 6.1, it is

<div id="ContentWrapper" style="height: 4276px;">
    <div id="FullScreenMask" style="display: none;"></div>
    <iframe width="100%" height="500" frameborder="0" allowfullscreen="" id="ContentFrame" src="/content/xxx/testhome.html" style="height: 4276px;"></iframe>
</div>

Any suggestion for fix this?

Thanks in advance.

26 Replies

Avatar

Level 10

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

Avatar

Former Community Member

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.

Avatar

Level 1

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

Avatar

Former Community Member

No, we do not find the solution. We switched to use the classic mode for the content edit to avoid this issue.

Avatar

Employee

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

Avatar

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!

Avatar

Level 1

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.

Avatar

Level 5

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

Avatar

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.

Avatar

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.

Avatar

Administrator

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

~kautuk



Kautuk Sahni

Avatar

Level 1

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

Avatar

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); }); } } };

Avatar

Administrator

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

Avatar

Level 2

Find the styling class that applies negative margin-bottom value and exclude it in edit mode.

Avatar

Level 1

We were using Material Design Lite. With the help of Adobe Support, we identified this class as the culprit:

.mdl-layout__container {

    position: absolute;

    width: 100%;

    height: 100%;

}

I had to remove it completely (showed up twice in the OOTB MDL CSS), but that did the trick.

Avatar

Level 2

Hi,

This bug is also happening in AEM 6.3. Can anyone tell me if there's a hotfix I can install to get this resolved?

Thank you, I appreciate it.

Avatar

Level 10

I would contact Support to see if a hotfix is needed.