Closed
Bug 895716
Opened 11 years ago
Closed 11 years ago
[fig] TEST-UNEXPECTED-FAIL | testNewTab | GeckoEventExpecter - blockForEvent timeout: DOMContentLoaded
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(firefox24 unaffected, firefox25 unaffected, firefox26 verified)
VERIFIED
FIXED
Firefox 26
Tracking | Status | |
---|---|---|
firefox24 | --- | unaffected |
firefox25 | --- | unaffected |
firefox26 | --- | verified |
People
(Reporter: Margaret, Assigned: AdrianT)
References
Details
(Keywords: intermittent-failure, Whiteboard: fixed-fig)
Attachments
(1 file, 2 obsolete files)
3.26 KB,
patch
|
Margaret
:
review+
|
Details | Diff | Splinter Review |
This was failing on my try run, and seems to still be failing on fig. I can reproduce locally, so I'll investigate.
Reporter | ||
Comment 1•11 years ago
|
||
It appears the issue here is that the second call to addTab is failing to enter a URL. The problem happens here:
https://hg.mozilla.org/projects/fig/file/f248fe823002/mobile/android/base/tests/BaseTest.java.in#l640
I tried using focusUrlBar() instead of this call to manually click on the EditText, but that caused addTab to just always fail :/
Maybe Adrian or Geoff can help me figure out what's going wrong here.
Assignee | ||
Comment 2•11 years ago
|
||
I can look into this and help investigate
Comment 3•11 years ago
|
||
(Adding keyword so this shows in TBPL's bug suggestions)
Keywords: intermittent-failure
Assignee | ||
Comment 4•11 years ago
|
||
When clicking on the element I see a warning about the element not having a registered observer. I changed it to clickOnText and since every new tab will load about:home the title, "Enter Search or Address", will always be displayed so the click should not fail. I also added a delay to wait for the text "BOOKMARKS" after clicking add_tab in order to make sure that about:home was loaded.
I tested this locally and it works every time. Please run a tryserver run since I don't know and couldn't find how to run this on FIG on the tryserver
Attachment #778381 -
Flags: review?(margaret.leibovic)
Reporter | ||
Comment 5•11 years ago
|
||
Comment on attachment 778381 [details] [diff] [review]
testNewTab fix v1
Review of attachment 778381 [details] [diff] [review]:
-----------------------------------------------------------------
Thanks for the patch! This does work, but I'd really like to see us move away from hard-coding strings like this. Could you pull them into constants at the top of the file?
::: mobile/android/base/tests/BaseTest.java.in
@@ +638,2 @@
>
> + // Since the Awesomescreen is about:home every new tab will have this title
We shouldn't talk about the "awesomescreen" in comments, since that doesn't actually exist anymore. Also, this isn't actually the title, but placeholder text that's shown because the title is empty. So maybe a better comment would be "The new tab will have a blank title, so click on the urlbar placeholder text".
Attachment #778381 -
Flags: review?(margaret.leibovic) → feedback+
Reporter | ||
Updated•11 years ago
|
Assignee: margaret.leibovic → adrian.tamas
Assignee | ||
Comment 6•11 years ago
|
||
Defined the strings as variables and changed the comment to your suggestion
Attachment #778381 -
Attachment is obsolete: true
Attachment #779172 -
Flags: review?(margaret.leibovic)
Reporter | ||
Comment 7•11 years ago
|
||
Comment on attachment 779172 [details] [diff] [review]
newTabFigFix.patch v1.1
Review of attachment 779172 [details] [diff] [review]:
-----------------------------------------------------------------
Thanks for the updated patch! I just have one more small comment.
::: mobile/android/base/tests/BaseTest.java.in
@@ +42,5 @@
>
> private static final String TARGET_PACKAGE_ID = "org.mozilla.gecko";
> + private static final String LAUNCH_ACTIVITY_FULL_CLASSNAME ="@ANDROID_PACKAGE_NAME@.App";
> + public static final String TITLE_PLACEHOLDER_TEXT = "Enter Search or Address";
> + public static final String ABOUT_HOME_BOOKMARKS_TAB_TITLE = "BOOKMARKS";
These can be private for now, since they're not used anywhere else.
Nit: Could you put these variables in their own newline-separated section, with a comment saying they are strings that are in the UI? It would be similar to how there's a section down below for IDs of UI views:
https://hg.mozilla.org/projects/fig/file/f248fe823002/mobile/android/base/tests/BaseTest.java.in#l63
Attachment #779172 -
Flags: review?(margaret.leibovic) → review+
Assignee | ||
Comment 8•11 years ago
|
||
(In reply to :Margaret Leibovic from comment #7)
> Comment on attachment 779172 [details] [diff] [review]
> newTabFigFix.patch v1.1
>
> Review of attachment 779172 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> Thanks for the updated patch! I just have one more small comment.
>
> ::: mobile/android/base/tests/BaseTest.java.in
> @@ +42,5 @@
> >
> > private static final String TARGET_PACKAGE_ID = "org.mozilla.gecko";
> > + private static final String LAUNCH_ACTIVITY_FULL_CLASSNAME ="@ANDROID_PACKAGE_NAME@.App";
> > + public static final String TITLE_PLACEHOLDER_TEXT = "Enter Search or Address";
> > + public static final String ABOUT_HOME_BOOKMARKS_TAB_TITLE = "BOOKMARKS";
>
> These can be private for now, since they're not used anywhere else.
I would not make these private since it's useful to wait for the tabs titles to check the new about:home is loaded and also for the title placeholder in some cases
> Nit: Could you put these variables in their own newline-separated section,
> with a comment saying they are strings that are in the UI? It would be
> similar to how there's a section down below for IDs of UI views:
> https://hg.mozilla.org/projects/fig/file/f248fe823002/mobile/android/base/
> tests/BaseTest.java.in#l63
I'll fix this and submit a new patch
Assignee | ||
Comment 9•11 years ago
|
||
Separated the strings in a new section and decided to make them private and if someone needs them in other tests they can just set them public then.
Attachment #779172 -
Attachment is obsolete: true
Attachment #779239 -
Flags: review?(margaret.leibovic)
Reporter | ||
Comment 10•11 years ago
|
||
Comment on attachment 779239 [details] [diff] [review]
testNewTab fix v1.2
Thanks!
Do you have level 3 commit access? If not, I can land this on fig for you.
Attachment #779239 -
Flags: review?(margaret.leibovic) → review+
Assignee | ||
Comment 11•11 years ago
|
||
I don't have level 3 commit access. I can only add patches to the tryserver.
Reporter | ||
Comment 12•11 years ago
|
||
(In reply to Adrian Tamas (:AdrianT) from comment #11)
> I don't have level 3 commit access. I can only add patches to the tryserver.
Okay, I'm working on merging m-c into fig right now, but I'll land your patch after I'm done. Thanks!
Assignee | ||
Comment 13•11 years ago
|
||
(In reply to :Margaret Leibovic from comment #12)
> (In reply to Adrian Tamas (:AdrianT) from comment #11)
> > I don't have level 3 commit access. I can only add patches to the tryserver.
>
> Okay, I'm working on merging m-c into fig right now, but I'll land your
> patch after I'm done. Thanks!
Thanks. BTW: is there anything special I should add to the commit message in order to push a patch to try for fig or do I have to push it to a special try address for fig? I only pushed to try patches on m-c
Reporter | ||
Comment 14•11 years ago
|
||
(In reply to Adrian Tamas (:AdrianT) from comment #13)
> (In reply to :Margaret Leibovic from comment #12)
> > (In reply to Adrian Tamas (:AdrianT) from comment #11)
> > > I don't have level 3 commit access. I can only add patches to the tryserver.
> >
> > Okay, I'm working on merging m-c into fig right now, but I'll land your
> > patch after I'm done. Thanks!
>
> Thanks. BTW: is there anything special I should add to the commit message in
> order to push a patch to try for fig or do I have to push it to a special
> try address for fig? I only pushed to try patches on m-c
You don't need to change the commit message for fig. You can push to try like normal from fig, and your push will just include all the parent changesets on fig that aren't on m-c already (that's what I did when I was working on bug 880060).
The patch here is pretty low-risk, and I verified it made the test pass locally for me, so I just pushed it to fig:
https://hg.mozilla.org/projects/fig/rev/31d437a61ce1
Whiteboard: fixed-fig
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment 17•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 26
Updated•11 years ago
|
Comment 18•11 years ago
|
||
Since there are no more fails, I’m setting this as verified.
Updated•11 years ago
|
Status: RESOLVED → VERIFIED
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•