Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#38 | remove_autosubmit-1319528-37.patch | 760 bytes | sheldonkreger |
#36 | remove_autosubmit-1319528-36.patch | 672 bytes | sheldonkreger |
#35 | remove_autosubmit-1319528-35.patch | 759 bytes | sheldonkreger |
#24 | media-browser-view-library-exposed-form-submit-problem-1319528-24.patch | 717 bytes | ndobromirov |
#11 | media-browser-enter-submit-frontpage-1319528-11.patch | 807 bytes | j0rd |
Comments
Comment #1
justkristin CreditAttribution: justkristin commentedSame problem here. Cannot use "view library" tab at all.
Comment #2
jamiecuthill CreditAttribution: jamiecuthill commentedIt is worth following these related issues
#1324238: Not all views exposed forms auto-submit correctly (was: Clean up and improve auto-submit.js0
#1217948: exposed filter with autosubmit and ajax loses keyboard focus
Comment #3
Dave ReidThere is not much we can do here besides improve Views and it's autosubmission functionality.
Comment #4
gmclelland CreditAttribution: gmclelland commentedUsing 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.
Comment #5
gmclelland CreditAttribution: gmclelland commented-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?
Comment #6
gmclelland CreditAttribution: gmclelland commentedRelated issues
#1396700: Media Browser "View Library" Submit button redirects back to homepage, instead of closing modal and adding media file
#1362386: Better user experience for searching in "View Library"
#1293676: Views Library Filter Bugs
Comment #7
gmclelland CreditAttribution: gmclelland commentedRegarding 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.
Comment #8
gmclelland CreditAttribution: gmclelland commentedFYI.. Ctools issue was committed #1324238: Not all views exposed forms auto-submit correctly (was: Clean up and improve auto-submit.js0
Comment #9
girishmuraly CreditAttribution: girishmuraly commentedRegarding #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.
Comment #10
j0rd CreditAttribution: j0rd commentedThere'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?
Comment #11
j0rd CreditAttribution: j0rd commentedI'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.
Comment #12
DamienMcKennaThe 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 :)
Comment #13
DamienMcKennaThe 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.
Comment #14
DamienMcKennaScenario that triggers the error:
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.
Comment #15
WigglyKoala CreditAttribution: WigglyKoala commentedI 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.
Comment #16
Elijah LynnI 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.
Comment #17
Elijah LynnComment #18
rooby CreditAttribution: rooby commentedEven 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.
Comment #19
ParisLiakos CreditAttribution: ParisLiakos commentedyeah i keep disabling it as well..maybe we should ship default view with this disabled
Comment #20
rooby CreditAttribution: rooby commentedAs 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?
Comment #21
aaron CreditAttribution: aaron commentedI have committed the patch at #11. Thanks for the hard work everyone. I suppose that for the other issues, we can open new tickets.
Comment #23
drupalninja99 CreditAttribution: drupalninja99 commentedI 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.
Comment #24
ndobromirov CreditAttribution: ndobromirov commentedExperienced 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.
Comment #25
r3k1n CreditAttribution: r3k1n commentedThe patch doesn't work.
Comment #26
Elijah Lynnr3k1n - 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?
Comment #27
curro CreditAttribution: curro commentedWe 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.
Comment #28
curro CreditAttribution: curro commentedFinally, 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.
Comment #29
dbrouard CreditAttribution: dbrouard commentedHi, 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.
Comment #30
klonos...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.
Comment #31
j0rd CreditAttribution: j0rd commented@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.
Comment #32
Anonymous (not verified) CreditAttribution: Anonymous commentedRunning into this problem today with the latest dev release. Experiencing this exact problem: https://drupal.org/node/1396700
Ideas?
Comment #33
kieranb22 CreditAttribution: kieranb22 commentedAlso 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.
Comment #34
Devin Carlson CreditAttribution: Devin Carlson commentedThis is caused by/is a duplicate of #690748: Views exposed filters don't work in block display.
I think our options are to either refactor the media browser to use pages with paths or to do something like #1975836: Exposed form in media browser view plugin - apply goes to wrong url..
Comment #35
sheldonkreger CreditAttribution: sheldonkreger commentedAs per comment #19, I have a patch here which removes the autosubmit which is causing problems. It also adds a reset button.
Comment #36
sheldonkreger CreditAttribution: sheldonkreger commentedSadly, the 'reset' button will display the home page. So, here is a patch which removes it :-(
Comment #38
sheldonkreger CreditAttribution: sheldonkreger commentedWow, rough day. Here is a patch that actually works.
Comment #39
longlivelance CreditAttribution: longlivelance commentedComment #40
alex.skrypnykWorks great in production. Tested by multiple in-house QAs.
Comment #41
gmclelland CreditAttribution: gmclelland commentedJust 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.
Comment #42
sheldonkreger CreditAttribution: sheldonkreger commentedI can see Devin's point in #34, but my patch can fix the problem right now. The auto-submit
buttonis 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.Comment #44
aaron CreditAttribution: aaron commentedCommitted to http://drupalcode.org/project/media.git/commit/d7acfdd.