-
2007-06-26
kbuck320
While using IE7, the media manager popup window has two issues .. firstly, that scrolling down a long list of images is nearly impossible. Hard to describe, you click on the down scroll bar, and it barely moves.
Second, upon selecting an image you want in the edit of the wiki page you are working on, media manager will usually refuse to populate that link into the document.
Using Firefox, none of the above occurs.
-
2007-06-26
andi
This was tried on two different machines and could not be reproduced. Can you give any additional info?
-
2007-06-26
kbuck320
Very interesting. I've tried this on two desktops and a laptop running IE7, and they all misbehave the same way.
Upon bringing up the Mediamanager pop-up window .. we have a namespace with 260+ images. The window takes 30-40 seconds to load in all those thumbs. When complete, you can tell there's something immediately wrong because the scroll bars on the right do not indicate a "long list". (Hard to describe. You know how there's 3 parts to a scroll bar, the top empty space, the actual bar, then the lower empty space? If the list is short, the "empty space" will be short, if long, the "empty space" will be long, and you can drag the "bar" down to the bottom.) In this scenario, with 260+ images, if I grab the bar and move it as far down as it goes, it will move the window down perhaps 2-3 images. When the image you need is alphabetically far away, it takes forever to scroll down. I hope I've explained that in enough detail. -- This misbehavior occurs with both "Hide Details" checked and unchecked.
The second problem, which is the biggest, is that once you do find the image you need, and click the file name, it does NOT take the file name and plop it in the wiki edit window (as Firefox will do). With IE, the MM window's right pane (where the images were) goes blank and nothing happens.
If you can't replicate this .. I'm not sure what to say, as it performs the same on all 3 of my PCs. My first thought would be if my IE had some plugin that was interfering .. but the PC I just tried it on, has no plugins (beside flash, shockwave, the common ones.)
-
2007-06-26
andi
So what happens when you have fewer images in your namespace? Say ten or 15. Does scrolling work? Does inserting work? What exact Version of IE7 do you use? On which OS?
-
2007-06-26
kbuck320
Indeed, the problem is the number of images. I tried it with two other namespaces. The first had only 1 image. That worked perfectly. The image came up, and when I clicked on it, the window disappeared, and the filename was put into the wiki edit page.
I tried it again on a namespace with about 20 images .. same problems. Scrolling didn't work correctly, and when I clicked on an image, the window did NOT close, nor did it put the filename in the wiki edit page.
-
2007-06-26
kbuck320
Oh, sorry, forgot the stats. Win XP Pro SP2 with all the updates. IE7 7.0.5703.11
-
2007-11-30
allkaro
I have the same issue, the problem occures when you have more image rows than popup height, when IE creates a scoll bar.
WIN XP Pro SP2 IE 7.0.5730.11
Windows Server 2003 IE 7.0.5730.11
Gutsy 7.10 FF 2 works fine ;-)
-
2008-01-15
dschreck
Any progress on this issue? This is happening to me as well. Note, this happens even when connected to the wiki as admin.
IE 7.0.5730.11 on XP Pro
-
2008-02-15
andi
The initital bug report has no DokuWiki version reported. What versions do you use?
-
2008-02-15
allkaro
Hi Andy, I am using the latest stable version 2007-06-26b.
-
2008-02-28
jamesvl
I can confirm the buggy behavior
Also on WinXP SP2, IE7, release 2007-06-26
Steps to reproduce:
* Edit any wiki page, even as admin, using IE7.
* Bring up the Mediamanager.
* The media manager must list at least 3-4 items on it. If it doesn't, add more or choose a namespace that has more items.
* Shrink the vertical height of the media manager window so that only one of the available items can be seen. (IE7 should display two separate vertical scroll bars on the right side.
* Try to click on the title of any of those items to add it to the page.
Expect to see:
Proper wiki text added to the Edit pane.
Actually see:
Right-side content (the item list) in the media manager disappears. No wiki text is added to my edit pane.
If I choose another namespace //or// resize the media manager window, the right-side content reappears. Clicking *anywhere* in the right-side pane of the item list causes the content to disappear. This leads me to believe it's a bug in the JavaScript/AJAX that adds content to that pane for IE7. When the window is too small to show items, links never receive the mouse click event to send the proper wiki text to the editor window.
Temporary work-around:
If you expand the vertical height of the media manager so that nearly all items in the list can be seen at once, the window behaves as expected. Depending on your screen height, you may have to create new namespaces so that the list doesn't grow too long.
I'll post any progress I make resolving this, since it's obstructing my intranet users on a production system. :) If anyone has seen something like this crop up before, hints or ideas are welcome.
-
2008-03-12
ach
Sorry, I still cannot reproduce this. Even with the latest detailed description ...
(Same conditions: WinXP SP2, IE7, DokuWiki version 2007-06-26b)
So ... what is different? Any special plugins that might interfere with the JS? Do the images have to be of a special kind (size, format, whatever)?
-
2008-03-13
kbuck320
We eventually "solved" this when we swapped out the template for a different one. -- So .. if you want to re-create this, it's important to have the standard templates/css, etc.
Also remember .. it only happens when there are dozens of images, so make sure you test it on a namespace with lots of images.
-
2009-01-12
andi
Is this still an issue with the latest stable release, or more important with a current devel snapshot?
-
2009-01-14
dschreck
This appears to be fixed when using a more current dev snapshot. My snapshot is from mid november (i don't know a build date, can i get that easily?).
-
2009-01-16
andi
seems to be fixed