The form element is output with the wrong URL when blocks have exposed filters.
This is because the block display handler relies on the base handler returning a relevant URL. Given blocks don't have a path, this bug must have been around for a long time.
The proposed solution (see patch in comment #3) is to set the url/path to the current page's alias for blocks.
This bug has a lot of symptoms, including the one originally reported:
---------------
Hi,
There seems to be a bug with block displays of views that contain exposed filters. I typically do some testing for browsers without Javascript to check how search engines would crawl the site and noticed this behavior.
The expected behavior would be that the view appends the variables to the URL if javascript is not enabled. For page displays everything works fine, however block displays break and visitors always end up on the homepage (see 3) as the path to the page on which the block is placed (1) does not get added to the URL.
Example:
1) Random URl with view and exposed filters: www.example.com/path/to/view
2) URL if display is "page" and javascript disabled: www.example.com/path/to/view?var1=val1&var=val2
3) URL if display is "block" and javascript is disabled: www.example.com/?var1=val1&var=val2
In other words, a visitor with a browser without javascript support visits page (1), selects items in the exposed filters, hits submit and either ends up on (2) if the display is page (works fine as expected) or (3) if the display is block (not as expected = bug).
Any idea how to fix this? I assume views would need to check on which page the block is placed and form the URL pattern accordingly.
Cheers, J.
---------------