Bug #23582

Docheader (save, save+view, save+close etc) missing

Added by Soren Malling over 9 years ago. Updated almost 9 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


Editing/creating new elements in any tables, no buttons are shown in the top.

Check out screenshot

(issue imported from #M15771)

missing-docheader.png View (18.6 KB) Administrator Admin, 2010-09-23 09:43

doc-header-bug.png View (14.7 KB) Administrator Admin, 2010-09-29 16:35

typo3core_bugfix_15771_trunk.patch View (443 Bytes) Administrator Admin, 2011-01-13 22:38

T3X_testdocheader-0_0_0-z-201101132324.t3x (6.53 KB) Administrator Admin, 2011-01-13 23:25

15771.patch View (373 Bytes) Administrator Admin, 2011-02-07 15:40

Related issues

Duplicated by TYPO3 Core - Bug #23642: Toolbar disappears in the backend Closed 2010-09-29
Duplicated by TYPO3 Core - Bug #23777: selecting a Clipboard hides save- and other buttons Closed 2010-10-18
Duplicated by TYPO3 Core - Bug #24636: moving of docheader when expanding and collapsing typoscript in object browser Closed 2011-01-18


#1 Updated by Hauke Haller over 9 years ago

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

#2 Updated by Björn Pedersen over 9 years ago

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

#3 Updated by Björn Pedersen over 9 years ago

Further informations:

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

#4 Updated by Björn Pedersen over 9 years ago

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.

#5 Updated by Björn Pedersen over 9 years ago

Update: changing
.x-border-layout-ct {
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.

#6 Updated by Björn Pedersen over 9 years ago

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

#7 Updated by Steffen Kamper over 9 years ago

I added a test extension which reproduce the behaviour.

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

#8 Updated by Björn Pedersen over 9 years ago

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.

#9 Updated by Stefan Galinski over 9 years ago

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?

#10 Updated by Ernesto Baschny over 9 years ago


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.

#11 Updated by Stefan Galinski over 9 years ago

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-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.

#12 Updated by Björn Pedersen about 9 years ago

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

#13 Updated by Ingo Renner about 9 years ago

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

#14 Updated by Ernesto Baschny about 9 years ago

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

#15 Updated by Stanislas Rolland about 9 years ago

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.

#16 Updated by Steffen Kamper about 9 years ago

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.

#17 Updated by Steffen Kamper about 9 years ago

I uploaded a working test extension.

#18 Updated by Steffen Kamper almost 9 years ago

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

#19 Updated by Steffen Kamper almost 9 years ago

finally committed to 4_5 and trunk rev 10418/10419

Also available in: Atom PDF