Closed
Bug 1215351
Opened 9 years ago
Closed 6 years ago
Remove distinction between the Search app and Browser app
Categories
(Firefox OS Graveyard :: Gaia::UI Tests, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: jlorenzo, Unassigned)
References
Details
+++ This bug was initially created as a clone of Bug #1205262 +++ This is a follow-up from bug 1203060, see bug 1203060, comment 14. We have this Search app and Browser app. http://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/apps/search/app.py http://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/apps/search/regions/browser.py When we now have a test, what usually happens: search = Search(self.marionette) search.launch() browser = search.go_to_url(some_url) This doesn't make sense. Browser and Search are almost the same, except Browser has some browser extra browser UI and Search has this start page that Browser doesn't have. Currently, you can't do browser.go_to_url(some_url) for example, because Browser doesn't have that method. I propose to combine these 2 app objects and add 2 properties, is_browser and is_private_browser so that tests can distinguish between the 3 different states. I could also make sure that methods that are specific to one/two specific state(s) give a nice failure when the app object is currently not in that state. What do you think? Btw, this Browser and Search app thing was written in: https://github.com/mozilla-b2g/gaia/pull/23467
Reporter | ||
Comment 1•9 years ago
|
||
(In reply to Martijn Wargers [:mwargers] (QA) from in bug 1205262 comment #8) > Regarding comment 2, I guess that's the way to go here. > In that case, I think we want something like this: > - BrowserBase class that contains everything that the various browser > objects have in common. > - Search(Base) -> BrowserHomePage(BrowserBase) > - Browser(Base) -> BrowserWindow(BrowserBase) > - PrivateWindow(Browser) -> PrivateBrowserWindowHomePage(BrowserBase) > - PrivateWindow(Browser) -> PrivateBrowserWindow(Browser) => Yup! Looks good > We talked about this in yesterday's meeting, Johan. You mentioned something > of keeping backwards compatibility for a while for other consumers, but I > don't recally very well on how to do that. What did you have in mind? The thing we could do is: 1. Instead of renaming the Classes, we copy them and rename the copies. 2. In the original class, we use the deprecation warning[1], so users are aware of the changes to do 3. After a while, we remove the deprecated classes. [1] https://docs.python.org/2/library/exceptions.html#exceptions.DeprecationWarning
Comment 2•6 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•