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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

justkristin’s picture

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

Dave Reid’s picture

Status: Active » Postponed

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

gmclelland’s picture

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.

gmclelland’s picture

-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?

gmclelland’s picture

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.

gmclelland’s picture

girishmuraly’s picture

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.

j0rd’s picture

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?

j0rd’s picture

Status: Active » Needs review
FileSize
807 bytes

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.

DamienMcKenna’s picture

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 :)

DamienMcKenna’s picture

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.

DamienMcKenna’s picture

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.

WigglyKoala’s picture

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.

Elijah Lynn’s picture

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.

Elijah Lynn’s picture

Status: Needs work » Reviewed & tested by the community
rooby’s picture

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.

ParisLiakos’s picture

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

rooby’s picture

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?

aaron’s picture

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.

drupalninja99’s picture

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.

ndobromirov’s picture

Status: Needs work » Needs review
FileSize
717 bytes

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.

r3k1n’s picture

The patch doesn't work.

Elijah Lynn’s picture

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?

curro’s picture

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.

curro’s picture

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.

dbrouard’s picture

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.

klonos’s picture

...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.

j0rd’s picture

@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.

Anonymous’s picture

Issue summary: View changes

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

Ideas?

kieranb22’s picture

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.

Devin Carlson’s picture

sheldonkreger’s picture

As per comment #19, I have a patch here which removes the autosubmit which is causing problems. It also adds a reset button.

sheldonkreger’s picture

Sadly, the 'reset' button will display the home page. So, here is a patch which removes it :-(

Status: Needs review » Needs work

The last submitted patch, 36: remove_autosubmit-1319528-36.patch, failed testing.

sheldonkreger’s picture

Wow, rough day. Here is a patch that actually works.

longlivelance’s picture

Status: Needs work » Needs review
alex.skrypnyk’s picture

Status: Needs review » Reviewed & tested by the community

Works great in production. Tested by multiple in-house QAs.

gmclelland’s picture

Just to the clarify on how this works based on my testing. The patch in #38 works for me as well. It does this by removing the auto submit feature in views. This prevents the view from automatically refreshing as the person is typing or choose from the select options. It also removes the Reset button because clicking the Reset button will cause the homepage to load inside of the modal dialog.

sheldonkreger’s picture

I can see Devin's point in #34, but my patch can fix the problem right now. The auto-submit button is pretty terrible anyway, as it will start searching if you pause while you're typing. It just generally feels buggy and I'd like to remove it from this already bug-ridden modal.

  • aaron committed d7acfdd on 7.x-2.x
    Issue #1319528 by sheldondreger, ndobromirov, j0rd: Media browser view...
aaron’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

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