Get wrong browser object for non top view in hierarchy about widgetastic.core HOT 7 OPEN

Actually not. The base Browser was designed as an immutable set of operations which other components rely on.

If specific things are needed, you can:

• add new methods that implement specific things in your browser subclass
• request a backwards-compatible change in WT browser method (add a parameter or whatever).
• use an existing hook in plugin class
• add a new hook into the Plugin class and add the hook calls in the particular browser methods, that way extensions altering the behaviour of the browser can be done without harming vanilla browser's behaviour.

from widgetastic.core.

@RonnyPfannschmidt Perhaps a custom super wrapper that "unwraps" the underlying browser from its wrapping would do. Instead of super(MyBrowser, self) one would call something like self.super(MyBrowser) and it would:

1. Figure the unwrapped object
2. call super(...) with it
3. Rewrap it again with the current wrapper.

And then the use would be like with normal super.

from widgetastic.core.

So basically we want to extend wait_for_element with one extra argument. To avoid copy pasting entire method body we just call super() and extend result with our stuff.

For top-level views calls to wait_for_element() via self.browser.wait_for_element() work ok, but for nested structure like the one @oshtaier provided - it fails on super() call (obj must be an instance or subtype of type), as self.browser for all nested views is BrowserParentWrapper, not the Browser itself.

Using it through self.root_browser.wait_for_element() works, but that doesn't sound like a right option to use root browser for every overwritten method to me.
Is that expected behavior and we aren't supposed to extend any browser's method or that's an issue with BrowserParentWrapper proxy implementation?

from widgetastic.core.

from widgetastic.core.

this change may necessitate a structural shift for wrapping browsers and locator using objects to sort out,
its possible we cant get around it before the new year

right now i don't have a idea for a solution

from widgetastic.core.

please also show the use-case you want to implement, due the nature of the issue (structural) it may be easier in the short term to find a different way to implement the use-case simply to avoid having to sort out the underlying issue in a timely manner

from widgetastic.core.

@RonnyPfannschmidt actually that was real use case.

I did it here:
https://github.com/SatelliteQE/airgun/pull/263/files#diff-b5de464875aa71a973dee2e139a855c9R130

but teammates said proper comment that it will be necessary to fix all (>50) places where we have not top level view.

from widgetastic.core.