Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

master templates should contain <base href="${request.resource_url(context)}" /> #219

disko opened this Issue Apr 17, 2013 · 6 comments


None yet
4 participants

disko commented Apr 17, 2013

Motivation: use of relative URLs in JS that are always relative to the context, regardless of wether the actual URL in the browser has a trailing slash or not.

Problem: While this is easy to add and solves what is described in motivation, it makes several existing tests fail. These seem to be errors in the tests, not in the tested code.


dnouri commented Apr 21, 2013

I've poked around a bit and found out why this happens.

In our forms, we have an empty action="" attribute. (Which might be a bit thing by itself because apparently browsers do weird things with an empty action="" attribute.)

mechanize does the wrong thing if action="", or if action is missing: If there's a 'base uri', it will use it to as the form's action. (Whereas the specs say you should use the document's URL if there's no action.) Here is where this is happening: https://github.com/jjlee/mechanize/blob/master/mechanize/_form.py#L1004

I suppose that given the 'stability' of mechanize (no new releases in the last two years), we could consider monkey patching in our own version of _ParseFileEx. I believe the 'right fix', but much more time intensive, would be to move away from zope.testbrowser (and doctests) and use WebTest for functional tests.


teixas commented Apr 25, 2013

There is a branch on zope.testbrowser where mechanize is been dropped in favor of WebTest: https://github.com/zopefoundation/zope.testbrowser/tree/webtest

Or do you prefer to really drop doctests and zope.testbrowser that is use of WebTest without wrappers around it?


dnouri commented Apr 25, 2013

Can you try it out on Kotti's tests?


teixas commented Apr 25, 2013

I started the migration to Webtest on doctests in a5df3af but there is still errors on browser.txt that need to be fixed.

Beyond that there is PR that fixes some minor bugs in zope.testbrowser I've found: zopefoundation/zope.testbrowser#3

Can you review?

mgedmin commented Apr 26, 2013

It is our goal to make the new WebTest-based zope.testbrowser as compatible as reasonably possible with the old mechanize-based version. I see some changes in a5df3af that look like workarounds for incompatibilities: e.g. the replacing of browser.reload() with browser.open(URL), and file_control.add_file(StringIO(...), ...) with file_control.add_file(StringIO(...).read(), ...). If you file bugs for them, we'll try to fix them!

(I'm also very curious about those mysterious image/jpeg; charset=latin1 content types.)

@disko disko referenced this issue in Kotti/kotti_tinymce Sep 30, 2013


Kottibrowser doesn't work on custom content types #19


disko commented Feb 5, 2014

6bb5ab1 makes this redundant.

@disko disko closed this Feb 5, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment