Bug #23582

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

Added by Soren Malling over 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
Start date:
2010-09-23
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

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

Check out screenshot

(issue imported from #M15771)


Files

missing-docheader.png (18.6 KB) missing-docheader.png Administrator Admin, 2010-09-23 09:43
doc-header-bug.png (14.7 KB) doc-header-bug.png Administrator Admin, 2010-09-29 16:35
typo3core_bugfix_15771_trunk.patch (443 Bytes) typo3core_bugfix_15771_trunk.patch Administrator Admin, 2011-01-13 22:38
T3X_testdocheader-0_0_0-z-201101132324.t3x (6.53 KB) T3X_testdocheader-0_0_0-z-201101132324.t3x Administrator Admin, 2011-01-13 23:25
15771.patch (373 Bytes) 15771.patch Administrator Admin, 2011-02-07 15:40

Related issues

Has duplicate TYPO3 Core - Bug #23642: Toolbar disappears in the backendClosedChris topher2010-09-29

Actions
Has duplicate TYPO3 Core - Bug #23777: selecting a Clipboard hides save- and other buttonsClosedErnesto Baschny2010-10-18

Actions
Has duplicate TYPO3 Core - Bug #24636: moving of docheader when expanding and collapsing typoscript in object browserClosedErnesto Baschny2011-01-18

Actions
#1

Updated by Hauke Haller over 10 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 10 years ago

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

#3

Updated by Björn Pedersen over 10 years ago

Further informations:

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

#4

Updated by Björn Pedersen over 10 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 10 years ago

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.

#6

Updated by Björn Pedersen over 10 years ago

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

#7

Updated by Steffen Kamper over 10 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 10 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 10 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 10 years ago

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.

#11

Updated by Stefan Galinski over 10 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-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.

#12

Updated by Björn Pedersen over 10 years ago

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

#13

Updated by Ingo Renner over 10 years ago

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

#14

Updated by Ernesto Baschny over 10 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 over 10 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 over 10 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 over 10 years ago

I uploaded a working test extension.

#18

Updated by Steffen Kamper about 10 years ago

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

#19

Updated by Steffen Kamper about 10 years ago

finally committed to 4_5 and trunk rev 10418/10419

Also available in: Atom PDF