(See also http://bugs.conkeror.org/issue375)
When choosing the browser-object to use with a command, conkeror looks in the following order: 1. An interactively specified browser object. 2. A binding default. 3. A page mode default. 4. A command default. But there's an exception. If the command default is a non-null literal value, then it overrides other values. But there's a weirder exception. If there is a binding default then the override doesn't happen and you get the binding default or the interactive object if that was specified. (A test suite for these precedence rules follows.) This is confusing and difficult to explain. We should make these rules consistent so that they're both intuitive to use and easy to implement. Perhaps the simplest change to make the rules consistent is to always have a non-null literal command default override other values. (An implementation follows.) There's no special treatment of binding or page-mode defaults in this scenario; they're not strictly needed because you can always define a new command rather than playing with those defaults. But perhaps it would be more consistent to allow any of the three default values to override if they are a non-null literal value. It may also be a good idea to forbid setting a browser-object on a binding or a page mode if the command has a non-null literal default browser-object. Thoughts? Regards, David. David Kettler (2): Tests for browser-object precedence. RFC: Simplify browser-object precedence. modules/element.js | 37 +++++++-------------- modules/walnut.js | 6 +++ tests/simple/browser-object-precedence.js | 50 +++++++++++++++++++++++++++++ 3 files changed, 69 insertions(+), 24 deletions(-) create mode 100644 tests/simple/browser-object-precedence.js -- 1.7.7 _______________________________________________ Conkeror mailing list [email protected] https://www.mozdev.org/mailman/listinfo/conkeror
