Closed Bug 1364329 Opened 7 years ago Closed 7 years ago

Intermittent browser/components/places/tests/browser/browser_toolbarbutton_menu_context.js | New bookmark item shouldn't be disabled -

Categories

(Firefox :: Bookmarks & History, defect, P2)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 58
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- disabled
firefox56 --- disabled
firefox57 --- disabled
firefox58 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: enndeakin)

References

Details

(Keywords: intermittent-failure, Whiteboard: [fxsearch])

Filed by: philringnalda [at] gmail.com https://treeherder.mozilla.org/logviewer.html#?job_id=98264821&repo=try https://archive.mozilla.org/pub/firefox/try-builds/philringnalda@gmail.com-cae57bd76140a82151d2c18e386693a24afa7c8b/try-win64-debug/try_win8_64-debug_test-mochitest-e10s-browser-chrome-3-bm127-tests1-windows-build25.txt.gz Since I keep seeing this in try pushes of trunk-as-beta, this'll probably be a quite frequent failure after the merge to beta on June 12th.
another funny test using waitForExplicitFinish along with add_task... But that's not the issue here. I wonder if the problem is related to the recent shrinking of the dropmarker button in bug 1363406 and Bug 1362100. Since the test tries to click in the center of the dropmarker that sounds plausible. It may actually be fixed now that the causing bugs are fixed.
Blocks: 1347543
Or maybe it's rather bug 1352364 that caused the shrinking.
Blocks: 1352364
No longer blocks: 1347543
I think the themes shrinking bugs have been fixed, so this should not happen anymore... resolving for now.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
This is indeed hitting on Beta55 post-merge :( https://treeherder.mozilla.org/logviewer.html#?job_id=106349198&repo=mozilla-beta
Status: RESOLVED → REOPENED
Flags: needinfo?(mak77)
Resolution: WORKSFORME → ---
I didn't work on the new theming changes, so I don't know if there may be code that would be shrinking the button in beta. I still think the primary cause here is that the button dropmarker part shrinks and synthesizeMouseAtCenter ends up failing.
Flags: needinfo?(mak77) → needinfo?(dao+bmo)
Whiteboard: [photon]
Flags: needinfo?(dao+bmo)
Whiteboard: [photon] → [photon-visual][triage]
Status: REOPENED → NEW
Flags: qe-verify-
Priority: -- → P2
Whiteboard: [photon-visual][triage] → [photon-visual]
Nihanth mentioned he had an idea for what was going on here.
Flags: needinfo?(nhnt11)
Whiteboard: [photon-visual] → [photon-visual][p3]
NI myself to disable the test given the lack of priority and the fact that it's the #2 most frequent orange on Beta right now.
Flags: needinfo?(ryanvm)
Disabling the test on beta is the right thing to do.
(In reply to Marco Bonardo [::mak] from comment #15) > Disabling the test on beta is the right thing to do. Agreed.
Flags: needinfo?(nhnt11)
Priority: P2 → --
Whiteboard: [photon-visual][p3]
This is still showing up as extremely frequent in the 57-as-Beta uplift simulations. Shall I plan to disable it again post-uplift?
Flags: needinfo?(mak77)
There should be no difference between Central and Beta at this point, since Photon will ride the train. In the screenshot, the context menu is not shown. I wonder if the problem is the way the test is disabling the panel animation, it's setting transition: none, but I suspect we instead should be using setAttribute("animate", "false") It may be interesting to test such a change, would have time to do a quick try run of it? s/BMB_menuPopup.setAttribute("style", "transition: none;");/BMB_menuPopup.setAttribute("animate", "false");/
Flags: needinfo?(mak77) → needinfo?(ryanvm)
I pushed the below patch to Try: https://hg.mozilla.org/try/rev/71a44dc2e6ad908e395cddd51b6d57ec3f620c69 Unfortunately, it didn't help (might have actually made things worse). https://treeherder.mozilla.org/logviewer.html#?job_id=129583968&repo=try
Flags: needinfo?(ryanvm) → needinfo?(mak77)
It actually made a difference, the screenshot is different, it now shows the contextual menu now... but it's cut! https://public-artifacts.taskcluster.net/ben1_KQKQq-73Pb6SWi9Lw/0/public/test_info//mozilla-test-fail-screenshot_s2T4NI.png Not sure what to think...
The functionality doesn't seem to be broken in reality, since it's just a test failure I think it will be fine to disable it in beta, we should probably try using waitForCondition, if we cannot find a meaningful event to wait before opening the contextual menu. Adding to the backloag as a P2, it's unlikely we can find resources for this before 58.
Flags: needinfo?(mak77)
Priority: -- → P2
Whiteboard: [fxsearch]
I think there's a chance, this could be fixed when bug 1404999 lands. Bug 1395619 feels similar in style, and both affected tests are dealing with the places context menu.
Depends on: 1404999
It is hard to know if bug 1404999 helped here. The last m-c failure was on 10th Oct (1404999 landed on 16/17th). The try pushes appear to be Ryan pushing the next release to beta simulations. So my only thought is that bug 1404999 could still help for the next beta, but we'd need a new beta-re-run to be sure. Ryan, will you be doing another of those soon?
Flags: needinfo?(ryanvm)
I've been running them during this cycle, yes (with this test disabled due to the frequency). I'll leave it enabled in the next run and see how it goes.
Flags: needinfo?(ryanvm)
Looks good from what I can see! I'll reopen the bug if it comes back.
Assignee: nobody → enndeakin
Status: NEW → RESOLVED
Closed: 7 years ago → 7 years ago
status-firefox58: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 58
You need to log in before you can comment on or make changes to this bug.