Project

General

Profile

Actions

Bug #16873

closed

Popup of pagetree shows up at the wong place (Typo3 4.1beta3)

Added by Rob Vonk almost 18 years ago. Updated over 17 years ago.

Status:
Closed
Priority:
Must have
Assignee:
Category:
-
Target version:
-
Start date:
2007-01-21
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.1
PHP Version:
4
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When i click on a page at the bottom of the pagetree and the frame is scrolled, the popupmenu is on the wrong place.

I tried with Firefox 2.0 and Internet Explorer 6.0.

I get different results when using maximized browser window or non-maximized browser window but never the correct place.

The attached picture shows one menu a little bit too high (left) and one far too high (right). Note that the cursor is in the picture too so that you can see where i clicked.

(issue imported from #M4817)


Files

typo3_41beta3_popup.png (77.8 KB) typo3_41beta3_popup.png Administrator Admin, 2007-01-21 11:45
bug_4817.patch (874 Bytes) bug_4817.patch Administrator Admin, 2007-02-02 11:37
Actions #1

Updated by Oliver Hader almost 18 years ago

I tested this only on Firefox 2, but can confirm the issue.

Also the translation of the item "History/Undo" of the popup-menu runs out of space for the german translation "Erstellungsverlauf/Rückgängig machen".

Actions #2

Updated by Benni Mack almost 18 years ago

Is this a issue with the new pagetree since 4.1beta3 or ddi this one exist before?

Actions #3

Updated by Rob Vonk almost 18 years ago

I didn't have the problem before but i migrated from 4.0 to 4.1 beta 3 so that doesn't really help.

The problem is easy reproducable:

Open a large tree so that the tree frame gets a scrollbar. Click on one item at the bottom of the screen and see the menu appear on the wrong place.

I think the problem must be the x,y determination. I think it takes the x,y from the complete frame instead of the x,y from the visible part. I tried to find the bug in the javascript but it's too complicated for me :) I can do php but never made an effort to learn javascript.

The workaround is easy b.t.w. Don't expand your tree so that it gets scrollbars. Everything is fine then.

Actions #4

Updated by Rob Vonk almost 18 years ago

Found a (half) fix. These lines in /typo3/template.php:

if (this.safari) {
GLV_x = GLV_xRel + (document.documentElement.scrollLeft ? document.documentElement.scrollLeft : document.body.scrollLeft);
GLV_y = GLV_yRel + (document.documentElement.scrollTop ? document.documentElement.scrollTop : document.body.scrollTop);
}

Alter the GLV_x and GLV_y when using safari. It works for me if i comment the if (this.safari) {
and the closing }

So it seems that this workaround is needed for more browsers than just safari. At least for (my) firefox 2.0 and IE 6.0

note added:

The safari exception wasn't in 4.0.x

see: http://typo3.org/fileadmin/typo3api-4.0.0/d4/d7a/template_8php-source.html

line 01350 and 01351

Actions #5

Updated by Benni Mack almost 18 years ago

This is a clickmenu issue, not a pagetree issue.
This will be fixed at the latest with the new clickmenu code (already done by me, but won't get into 4.1) which has a different, better cross-browser algorithm calculating the scroll offsets.

But Rob, you're right. This change (safari-if) was made in 06 in trunk, in 4.0 it still worked. I don't know who and why did the change. See trunk-revisions for template.php for that.

Actions #6

Updated by Rob Vonk almost 18 years ago

It seems that user 'typo3' checked the new code in:

http://svn.sourceforge.net/viewvc/typo3/TYPO3core/trunk/typo3/template.php?annotate=1879#l1349

(line 1345)

Actions #7

Updated by Benni Mack almost 18 years ago

so who is user "typo3"? if no one knows I think we should create a patch (for removing the if-clause; I could do that) for 4.1 so it "works" at least.

Actions #8

Updated by Oliver Hader almost 18 years ago

The SourceForge user "typo3" is that man that appears nearly in all TYPO3 related scripts, documents and whatever... (http://sourceforge.net/users/typo3/) ;-) In the ChangeLog appears "Fixed Safari context menu bug" for that revision.

@Rob: Thanks for the hint in template.php
See the ChangeSet for that revision: http://svn.t3.digitaldistrict.de/cgi-bin/trac.cgi/changeset/6114#file5

It shows, that nothing more but inserting the wrapping "if (this.safari) { | }" had been done. I guess this happened by accident and that we can remove the if-statement again. I also confirm that this solves/reverts the posioning issue.

Actions #9

Updated by Benni Mack almost 18 years ago

I uploaded the simple patch, hope this fixes it.

Actions #10

Updated by Ingmar Schlecht almost 18 years ago

Sent to the core list.

Actions #11

Updated by Oliver Hader almost 18 years ago

Committed to SVN Trunk by Ingmar.

Actions #12

Updated by Ingmar Schlecht almost 18 years ago

Indeed. Thanks for closing the issue, I forgot about it! :-)

Actions

Also available in: Atom PDF