When typing into the file name field on the "view library" tab of the media browser you can inadvertently cause the form to submit to the action rather than via ajax. I can usually reproduce this by typing into the file name field during the ajax callback to the server. The action on the exposed form is "/" so I end up with the homepage in the iframe.

I haven't yet found a solution.

Files: 
CommentFileSizeAuthor
#24 media-browser-view-library-exposed-form-submit-problem-1319528-24.patch717 bytesndobromirov
PASSED: [[SimpleTest]]: [MySQL] 92 pass(es).
[ View ]
#11 media-browser-enter-submit-frontpage-1319528-11.patch807 bytesj0rd
PASSED: [[SimpleTest]]: [MySQL] 5 pass(es).
[ View ]

Comments

Same problem here. Cannot use "view library" tab at all.

Status:Active» Postponed

There is not much we can do here besides improve Views and it's autosubmission functionality.

Using the patch http://drupal.org/node/1324238#comment-5360410 seems to help the issue with the inside of the modal being redirected to the home page 99% of the time. The other 1% happens randomly and I can't seem to reproduce the error.

#1217948: exposed filter with autosubmit and ajax loses keyboard focus - seems to suggest that when building your views you should always have your exposed filters be in a block instead of the view itself. Otherwise the autocomplete input will lose keyboard focus after every ajax submit. This happens because the whole contents of the view including the exposed filters get replaced. I'm experiencing this with the media module's "View library". Try typing part of the file name, an ajax request will be fired. Notice how you have to click back into the input field before you can continue typing the file name again?

To possibly solve that issue, can media module "View library" create it's exposed filters in a block that gets placed above the view?

Hope that helps someone.

-strange, when I went to edit the Media browser view, there is no setting for "Expose form in a block". Any thoughts on why this is missing?

Regarding my comment in #4 - So apparently you won't see the "Exposed form in block" option when editing the Media browser view because it is not a "Page" display. It has to be a Page display to see that setting.

Regarding #7 and the related issue here #1217948: exposed filter with autosubmit and ajax loses keyboard focus, it seems worthwhile to investigate why the 'Media browser' View display format cannot do 'Expose form in block'. Maybe its as easy as copying from the Page display format, because the media browser is a page afterall as it has a url. Ofcourse the other tricky thing would be placing the block on the media browser ajax return, but we could accomplish that by calling hook_block_view() directly or something like that.

There's another closed issue, where others are having the same problem here:
#1396700: Media Browser "View Library" Submit button redirects back to homepage, instead of closing modal and adding media file

@gmclelland & #8

From what I can tell, that patch did not resolve the issue. I am running latest stable of CTools & Views. Recent -dev versions of file_entity & media

The problem with the patch from #1324238 is that, while it's discarding "enter" from "ajax submitting" the form, it's allowing it's default event to bubble up in the DOM, and the default action for pressing enter in an input field on a form, is to submit the form.

Since this form's action is action="/", we end up with the homepage in the media browse popup dialog.

From debugging the CTools auto-submit.js, I don't see how it can solve this problem for anyone.

The CTools patch would need to check to see if e.keyCode === 13, then e.preventDefault(), or better yet, trigger the "AJAX submit". The problem is, while this makes sense for our needs with Media Browser Popup, I'm not sure if it makes sense for all other users of CTools.

So in our case, we might require preventingDefault() for all enters in our popup.

Does this problem still exist for other people?

Status:Active» Needs review
StatusFileSize
new807 bytes
PASSED: [[SimpleTest]]: [MySQL] 5 pass(es).
[ View ]

I've created a little hack patch, which will disable the handling of enter in any ctools autosubmit input.

Seems to resolve the issue for me.

Additionally, in ./js/plugins/media.views.js it looks like more use of $('.class', context) should be used.

The bug is quite amusing, it's possible to nest the popups so you end up with Media-inception! ;-)

The patch in #11 solves the problem for me, nicely done. I'm going to have someone else at Drupalcamp Atlanta review it and hopefully we'll be able to RTBC it :)

The patch doesn't resolve all events that triggers the homepage reloading, I'm trying to track down other scenarios and will update as I identify them.

Status:Needs review» Needs work

Scenario that triggers the error:

  • Apply the patch.
  • Open the media browser, then go to the Library tab.
  • Type something into the text filter.
  • While the AJAX event is running, type more characters (any characters!) into the text field.
  • The site's homepage will be reloaded into the popup iframe.

I'm tempted to say that the first patch might be worth committing just to rule out that one specific issue, but the rest need work.

I also think that it might be worthwhile committing the patch to solve some of the more common problems. This issue has been floating around for a while now and it would be good to see some progress on it.

I just applied this patch (#11) against 7.x-2.x-unstable7+38 (today) and it does significantly reduce the chance of the homepage getting loaded. I was able to reproduce it once but never again after that. I agree with #15 and think it would be better to have this in than not, even though as #14 suggests there may still be some edge cases.

+1 for a commit.

Status:Needs work» Reviewed & tested by the community

Even when it doesn't redirect you to the home page it still causes trouble.

If you are typing something longer it submits half way through, you lose whatever you typed since it submitted and you've searched for the wrong thing.

I have found the only way to make it user friendly is to disable autosubmit for that view.

yeah i keep disabling it as well..maybe we should ship default view with this disabled

As a side note, if you enable and click the the exposed form reset button, you also end up loading the home page.

Should I open a new issue for that or keep it in here?

Status:Reviewed & tested by the community» Fixed

I have committed the patch at #11. Thanks for the hard work everyone. I suppose that for the other issues, we can open new tickets.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Needs work

I am still getting this issue. It just loads the homepage into the browser when I type into the search box. And if I click on a pager link it clicks the first tab in the popup which makes me click back to the library tab.

Status:Needs work» Needs review
StatusFileSize
new717 bytes
PASSED: [[SimpleTest]]: [MySQL] 92 pass(es).
[ View ]

Experienced the issue because of a non-matched jquery selector for the input fields of the exposed form in ajax-enabled view.
Added the selector that fixes the issue.

The patch doesn't work.

r3k1n - Can you please be more detailed? 'The patch doesn't work' doesn't help us know about your issue.

Did the patch not apply at all?
Did it apply but not fix the issue?
Did it produce any errors?

We have applied both patches media-browser-enter-submit-frontpage-1319528-11.patch and media-browser-view-library-exposed-form-submit-problem-1319528-24.patch with no errors, but they don't resolve the issue reported.

We are using:
- Views 7.x-3.7
- Ctools 7.x-1.3
- Media 7.x-2.0alfa2+6-dev

Thanks in advance for your responses.

Finally, the only way we have found to avoid this issue was reinstalling drupal and all the modules. We don't know still which is the module that produces the error, but we continue to investigate.

Hi, I open a similar issue here https://drupal.org/node/2152865, and after applying the patches, the problem still happens.

I read the comments here, they were focusing on "don't submit the form if enter key is pressed", but my repro is different:

1. Open media browser, click "Library" tab
2. Type something in the search box, when the "in progress" icon appears, type again
3. Homepage is loaded into the frame.

As I wrote in my ticket, I can repro it once and again in Google Chrome, but not in Firefox.

...unrelated to this, but I just want to say that recently I had an issue with WYSIWYG + CKEditor where I solved a weird problem with the editor's toolbar buttons. It seemed to be some browser-side caching problem because in the end I managed to work around it in Firefox, but in Chrome it proved more difficult/complex.

@dbrouard Did you try patch 11, or just patch 24.

It looks like patch 24 doesn't include my change in patch 11.

Try patch 11 by itself, and let me know if that works for you.

NVM, I was confused.

Actually it looks like patch 11 is in media-alpha3, so no need to apply that patch.

Issue summary:View changes

Running into this problem today with the latest dev release. Experiencing this exact problem: https://drupal.org/node/1396700

Ideas?

Also have this exact problem with this release 7.x-2.0-alpha2. It occurs when I input a value in two fields in quick succession so that the two fields are auto-submitting at the same time.