Tracker has some test instructions.

I added the test instructions from joomlacode to the original post

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3919.

Tested and is working generated this code:

URL to testbed: http://gothard.dk/joomla/index.php?option=com_content&view=article&id=1:getting-started&catid=2:uncategorised&Itemid=101

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3919.

The code was ofcause filtered out - check it out on the testbed link.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3919.

@test,
This works when adding the image for the first time, When i re-edit the article already containing the image, one javascript error is coming when i open image modal by clicking on the "image" button.
It does not hamper the functionality, but error is coming so attaching the screen-shot of the error here.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3919.

@test it happen when i'm double-click on folder in frame


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3919.

I see the same issues as AnishaVora and tairedweb

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3919.

Thanks guys. I'll try to have a look at to these issues next week.

@test OK, but:

TypeError: u is undefined
...\/)?(([^:\/?#])(?::(\d))?)((\/(?:^?#)\/?)...


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3919.*

I can't seem to duplicated these errors in chrome. I'll try other browsers. What browsers are y'all using?

Nevermind, I'm finding them now.

This ought to fix it. Do you ever look at some code you wrote a while ago and think: how did this even work at all?

@test, tested on Joomla 3.3.6, 'Edit Article'

• Changing directories OK
• Using the select or the 'up' button, OK
• Select a directory, FAILED

ReferenceError: com_content is not defined
ImageManager.setFolder(this.options[this.selectedIndex].value, com_content, 55)

• Generating the img tag (or figure tag set) and inserting into the editor, OK

@anibalsanchez the 'Select a directory' bug is not related to this file (try it on a clean install, you'll see) so I'd prefer not to include it in this PR. The bug is actually in MediaModelManager (administrator/components/com_media/models/manager.php). It's a very easy fix:

$list = JHtml::_('select.genericlist', $options, 'folderlist', 'size="1" onchange="ImageManager.setFolder(this.options[this.selectedIndex].value, '.$asset.', '.$author.')" ', 'value', 'text', $base);

should change to

$list = JHtml::_('select.genericlist', $options, 'folderlist', 'size="1" onchange="ImageManager.setFolder(this.options[this.selectedIndex].value, ' . json_encode($asset) . ', ' . $author . ')" ', 'value', 'text', $base);

I'll put in a different PR for that one.

Here #5077

@test Ok with #3919 and #5077

@test
Joomla 3.4.0
Google Chrome 40.0.2214.111 Mac
with com_articles - New Article

OK:

• Browsing through folders -> OK
• Using "UP" Button -> OK
• Selecting Image -> OK
• Image Path is applied to field "Image URL" after selecting -> OK
• Selecting Image and Inserting into Joomla Article -> OK

Error:

• On browsing through folders the directory path is not changing like it did without the patch

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3919.}

@chalkin is this not fixed by #5077 ?

@okonomiyaki3000 the fix from #5077 is already applied in joomla 3.4.0 - but it's not fixing the problem with the current directory not showing up.

Specific the fixed line in #5077 I'm refering to:
administrator/components/com_media/models/manager.php Line 104

$asset = htmlspecialchars(json_encode(trim($input->get('asset', 0, 'cmd'))));

In this modal window, when I switched in a subfolder and upload an image it is allways stored in the images root folder, no matter in wich subfolder I actually am. This happend with and without this patch in J-3.4. As this behaviour is not in J-3.3.6, it seems to be a 3.4 bug.

@okonomiyaki3000
I've searched a while and found this bug not reported so far, so you can smash another bug with this PR.

@okonomiyaki3000 Could you please have a look at the issues mentioned? Thank you.

Rebased with latest staging but couldn't reproduce the bug. Everything is working perfectly in Chrome. @Chalkin @peterpeter , what browsers are you guys using?

Ah, you are using Chrome. Well, I can't imagine why you got this error. Any messages in Chrome's console?

I'm using chrome on mac (current chrome) - I will check in the evening if the problem still exists since it's been a while.

I've used FF on windows....I check it later on too, with different browsers

I have reproduced the reported issue.

If you navigate to a subfolder and upload an image, it works Ok.

However, if you choose a subfolder from "Directory", it shows the subfolder. But, when you upload an image, it is saved in / and jumps to /.

Thanks! That might help. I'll try it tomorrow.

Thanks for your help guys, this should fix it. The problem was that, in some cases a url was getting double encoded. There's an iframe that contains the current directory list and it gets changed when changing directories. This can happen by a link (clicking a folder in the list) which worked fine because it was a perfectly "natural" process. It can also happen by javascript (a result of using the folder select or 'up' button). The javascript way had a problem because I was forming the query string part of the url by using JQuery's $.param() function. That function is pretty convenient and even does url encoding automatically. You'd think that would be perfect but then the next step is to assign the url to frame.location.href. You might not know this (I didn't) but assigning a url to location.href also automatically url encodes. So this was resulting in a double encoding. Specifically, the / character was getting encoded as %2F and then that was getting encoded as %252F which is obviously a mess that makes no sense at all.

So now it's fine.

@text OK

conflicts, eh? We'll see about this...

Rebased with staging. Should merge now.

@anibalsanchez I think you meant to say @test OK

Ahhh fat fingers!!! @test OK

I have tested this item successfully on 95a3099

Tested successfully on Chrome / Os X

@okonomiyaki3000 can you fix merge conflicts? Than we can RTC based on @designbengel and @anibalsanchez 's tests

This can be easily fixed by a commiter:
remove JHtml::_('script', 'media/popup-imagemanager.min.js', true, true); from administrator/components/com_media/views/images/view.html.php and push just the scripts