1076040 - Repo nav bar doesn't appear on initial load

Status: VERIFIED FIXED

(Tree Management :: Treeherder, defect, P2)

Description

[Jonathan French (:jfrench)]

The repo nav-bar doesn't display on initial page load, at least on Firefox 32.0.3 latest release. Chrome is fine.

To reproduce
o launch Firefox with a clear cache
o https://treeherder.mozilla.org (production)

Expected
The UI draws in its entirety

Observed
The repo nav-bar is missing

Workaround
Force reload the page

I will attach accompanying screen grabs.

Comment 1

[Jonathan French (:jfrench)]

Attachment: initialLoad

Initial load appearance, missing the repo bar.

Comment 2

[Jonathan French (:jfrench)]

Attachment: afterReload

Correct appearance after forced reload.

Comment 3

[Ed Morley [:emorley]]

Yeah can repro.

Not ideal from a "treeherder first impression" POV, so raising priority slightly.

Comment 4

[Jonathan French (:jfrench)]

I've re-checked on Chrome after clearing my cache, and Chrome appears to suffer the same problem. Adjusting the bug title accordingly.

Comment 5

[Jonathan French (:jfrench)]

I may have a fix for this one. I'll assign myself, if I can confirm that.

Chrome displays the bug with a local server, but looks correct on dev/prod/stage. Whereas Firefox displays the bug in all.

Comment 6

[Jonathan French (:jfrench)]

Attachment: treeherder-ui-PR#219

Please see the above PR for review and status.

Comment 7

[Ed Morley [:emorley]]

Comment on attachment 8500639 [details] [review]
treeherder-ui-PR#219

(Without the review flag set, this will likely get overlooked :-))

Comment 8

[Jonathan French (:jfrench)]

(In reply to Ed Morley [:edmorley] from comment #7)
> Comment on attachment 8500639 [details] [review]
> treeherder-ui-PR#219
> 
> (Without the review flag set, this will likely get overlooked :-))

No probs Ed. :) Just to note, reviewers are notified immediately of the review request when the PR is opened in Github via the @camd, @wlach, @mdoglio, etc, and in addition to the PR list in Github which is checked daily. But I will ask in this weeks' mtg or in channel for their preference.

If it's some bugzilla metric-thing we need for data mining (eg. percentage of resolved bugs that received review, percentage of re-opened bugs that didn't receive review in a given fiscal year, etc) let me know.

I just didn't want to add admin overhead to the team. I figure like in TBPL every keystroke adds up. :)

Comment 9

[Ed Morley [:emorley]]

I'd just seen some PRs sit for a while, which made me think the PR queue wasn't being triaged regularly. I just didn't want your patch to get overlooked.

Also, much of the rest of Mozilla uses a patch/Bugzilla based workflow (even Gaia, whose canonical repo is on Github), which:
* Allows the use of dashboards such as http://harthur.github.io/bugzilla-todos/, which for me means I can both keep track of my incoming requests (ie: "things I need to do within 24hrs if possible to be respectful of others time") and also see which of my bugs is blocked on waiting for a response from someone (the "to nag" section). This is particularly important for people that work on non-github projects too, since it means everything is in one place.
* Means daily reminder emails are sent for overdue review, feedback and needinfo requests.
* Allows managers can opt into these overdue request reminders to see whether someone is overloaded or not.
* Means the "outstanding requests" count shown in the bugzilla UI (red circle top left if there are any outstanding) is reflective of the actual number of requests.
* Review history feature can be used, which shows people's historic response times - (eg https://bugzilla.mozilla.org/page.cgi?id=review_history.html&requestee=emorley%40mozilla.com - though data prior to the feature going live recently is unavailable, so the history is pretty short for now).

That said, I do empathise that having to update flags on a bug and things in github is a pain - so happy for people to be flexible if needs be :-)

Comment 10

[Jonathan French (:jfrench)]

Fair enough. Yup, I figured there was some dashboard affordances, visibility, or legacy processes it provided.

It would be really sweet if Github could set the Bugzilla review flag automatically when the PR is opened, and review+ the bug when the PR is merged by the merge-er. :) Much like that new Treeherder Bugbot account, whose comments are automatically injected into the Bugzilla bug on merge.

Obviously a few business rules to sort out for that transaction, but that would provide a beautiful passive workflow, to make the field change on the Bugzilla side. Since a PR is implicitly a review request, and a merge is implicitly an r+.

Comment 11

[Ed Morley [:emorley]]

Yeah that would be cool :-)

Comment 12

[Treeherder GitHub Bugbot]

Commits pushed to master at https://github.com/mozilla/treeherder-ui

https://github.com/mozilla/treeherder-ui/commit/83747f02ef7e078f30fddd4f0850f9d72a7007ce
Bug 1076040 - Ensure watched repo navbar appears on initial page load

https://github.com/mozilla/treeherder-ui/commit/41e441f221a9f4322399a024220db9fb13d273c5
Merge pull request #219 from tojonmz/missing-watched-navbar

Bug 1076040, 1075301- Ensure watched repo navbar appears on initial page load, open resultset in new tab

Comment 13

[Jonathan French (:jfrench)]

Verified fixed and working correctly on dev in both Firefox and Chrome.

Comment 14

[Treeherder GitHub Bugbot]

Commits pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/fabf22279002f96ad9e1b4071a0810288d8ca061
Bug 1076040 - Ensure watched repo navbar appears on initial page load

https://github.com/mozilla/treeherder/commit/d17478d69bbe9f54cd10d56c34b2d9eed21fb3a3
Merge pull request #219 from tojonmz/missing-watched-navbar

Bug 1076040, 1075301- Ensure watched repo navbar appears on initial page load, open resultset in new tab