TYPO3 Core

The #typo3-docheader-row1is't visible but still there in HTML.
It dissapeared, when saving in the Constant Editor. It's only dissapearing, when I've made changes in the Constant editor before. Reloading the whole backend brings it back.

Win XP, FF3.6.10

I can confirm this behaviour. After editing a template (setup) the doc-header is missing.

Further informations:

If i remove the "float:right" from buttongroup with firebug, the buttons appear.

More info: This happens , as so as a jump to an anchor for which scrolling is necessary is performed. In other words, there is some offset introduced that is wrong.

Update: changing
.x-border-layout-ct {
position:relative;
}
in firebug causes a layout recalculation and everything works again.

The offset amount is always 21px, so somehow one docheader row is missed in layout calculations after scrolling.

The 21 px missing on top are found again at the bottom. See attached screenshot.

I added a test extension which reproduce the behaviour.

Björn: .x-border-layout-ct change doesn't help, i have no change.

I meant dynamically toggling that property in firebug forces a re-calculation of the layout. Just changing it in the css has no effect, that is correct.

I tried to reproduce that issue with Chrome and Fx, but couldn't succeed. The demo extension didn't worked in 4.5 anymore (white page). Someone can write a step-by-step "How to Reproduce" howto? Maybe related to Windows?

Stefan:

Just go to the "Constant Editor", change any constant and hit "SAVE": The form will be saved and in the result page you will get moved by an anchor to the last edited constant.

This is when the whole content is shifted upwards, so that the doc header with the toolbar disappears. It won't appear even when you click on other modules. Only solution is to reload the whole backend again (or make Firefox re-layout by changing some CSS property via Firebug).

Several people (Kamper, Gebert, myself, ...) have tried to solve this issue (which was introduced by the removeal of the FRAMESET) but still there is no solution.

After some hours of investigation I found at least the source of the big move to the top into the topbar. Just remove the following css definition in viewport.css.

#typo3-navigationContainer-xsplit,
#typo3-navigationContainer-xcollapsed {
border-top: 22px solid #585858;
}

The main issue seems to be that ExtJS incorrectly calculates the height of some elements. Maybe someone else can find a solution based on this information. If not we can at least remove the css definition above until we find a proper solution.

Note: Also if you remove the css definition there are 3 additional pixels that seems to be related to the borders of the iframes. However the whole issue is very strange.

partly fixed by http://bugs.typo3.org/view.php?id=16032 (version 1).

just wanted to say I can confirm this issue, too. Quite annoying and a show stopper IMHO

Any link with an anchor (#) as a target will shift the content area up. It used to shift up by 22px, thus the docheader's icons were completely gone.

This was partly fixed in #23767, so now it only jumps up 2x, but it's still annoying and someone will have to tackle this!

=> bugday! ;)

Attached patch fixes part of the issue, that is, the pixel-high offset that appears on top of the navigation frame after saving, for example, with the constant editor.

But there remains an issue: the content frame is moved two pixels up on save. This is related to scrolling of the center region of the viewport, perhaps a ExtJs bug? If autoScroll is set to true on the center region of the viewport, the error disappears but useless scrollbars are displayed.

I also spent some time on this issue and i outsourced this to be solved by "Condor" - i wikk provide him the link to this issue to gather some infos.

I uploaded a working test extension.

for any reasons that are out of my scope, the attached patch fix this problem.

finally committed to 4_5 and trunk rev 10418/10419