Closed Bug 1442442 Opened 6 years ago Closed 6 years ago

"What's new" page is open of top of about:preferences

Categories

(Firefox :: Settings UI, defect, P5)

60 Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 61
Tracking Status
firefox58 --- unaffected
firefox59 --- unaffected
firefox60 --- wontfix
firefox61 --- fixed

People

(Reporter: StefanG_QA, Assigned: jens1o, Mentored)

References

Details

(Keywords: good-first-bug)

Attachments

(1 file, 1 obsolete file)

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 (20180301100139)

1. Open Nightly
2. Navigate to about:preferences
3. Under Nightly Updates, click "What's new" link

AR: "What's new" page is open on top of about:preferences
ER: "What's new" page to be open in new tab

All "Learn More" and "Nightly support" links are opened in new tab
I'm able to reproduce this as described (Nightly from 2018-03-05) - the What's new page replaces about:preferences, rather than opening in a new tab. Markus, can you confirm if this is a bug or expected/planned behavior?
Flags: needinfo?(mjaritz)
I am certain this is a bug.
It should open in a new tab. (As all other links)

I don't know of any designer was working on this, but I can not think of a reason to change the behaviour for only this case.
Flags: needinfo?(mjaritz)
I don't see at a glance why this particular link is behaving this way. Jared, I've given this a priority, can you suggest any next steps to get this fixed?
Flags: needinfo?(jaws)
Priority: -- → P5
https://searchfox.org/mozilla-central/rev/33cc9e0331da8d9ff3750f1e68d72d61201176cb/browser/components/preferences/in-content/main.xul#489 should have target="_blank" since they're using html:a here instead of <xul:label class="text-link"/>.
Flags: needinfo?(jaws)
Mentor: sfoster, jaws
Keywords: good-first-bug
I'd like to work on this for my good first bug.
(In reply to Tri from comment #5)
> I'd like to work on this for my good first bug.

I'll assign to you. Do you have a build environment set up to work on this? Let me know here or on IRC (sfoster in #fx-team) if you need any help getting going on this.
Assignee: nobody → trimeister.tran
Hi Tri, have you been able to make any progress on this bug?
Status: NEW → ASSIGNED
Flags: needinfo?(trimeister.tran)
Hello, I don(In reply to [slow to respond 3/26-3/30] Jared Wein [:jaws] (please needinfo? me) from comment #7)
> Hi Tri, have you been able to make any progress on this bug?

Hey Jared, sorry I don't think I'll able to work on this. Been really busy with school. Can you please un-assign me?
Flags: needinfo?(trimeister.tran)
Assignee: trimeister.tran → nobody
Status: ASSIGNED → NEW
I'd like to take that.

Is that okay for you Jared?

Probably I'll attach this here, I don't want to setup mozreview yet.
Flags: needinfo?(jaws)
Hi Jens, yes you may work on this. I'll assign it to you when you attach a patch. Thanks!
Flags: needinfo?(jaws)
Attached patch my-first.patch (obsolete) — Splinter Review
Attachment #8965943 - Flags: review+
Comment on attachment 8965943 [details] [diff] [review]
my-first.patch

Is it okay like this?

I'm unsure whether it is wanted to deliverr it like this. Am I really supposed to submit a diff?
Flags: needinfo?(jaws)
Attachment #8965943 - Flags: feedback+
Comment on attachment 8965943 [details] [diff] [review]
my-first.patch

Thanks, this patch looks good. Since this is your first bug, it's a good opportunity to learn how to create the proper patch formatting :)

The easiest way to do this is to commit your changes and push them to MozReview.

You can follow the steps at these two tutorials:
1. https://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/install.html
2. https://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/commits.html#submitting-commits-for-review

In your commit message you should include the bug number, a description of what you did to fix the bug, and end it with "r?jaws". The "r?jaws" part will flag me to review your changes.

The total commit message might look like "Bug 1442442 - Add target=_blank to the releasenotes link so clicking on it will open in a new tab. r?jaws" (minus the quotation marks).
Attachment #8965943 - Flags: review-
Attachment #8965943 - Flags: review+
Attachment #8965943 - Flags: feedback+
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Flags: needinfo?(jaws)
Okay, I'll try to set it up now. Thanks for the feedback.
```
Jens@Jens-Laptop /c/nginx/html/projects/firefox
$ hg push review
pushing to https://reviewboard-hg.mozilla.org/autoreview
searching for appropriate review repository
redirecting push to https://reviewboard-hg.mozilla.org/gecko
(adding commit id to 1 changesets)
```

It's not doing anything further after waiting around for a couple of minutes. Can I contact you privately so you can help me?

Tired of that problem for close of half an hour.
Flags: needinfo?(jaws)
That is very strange. My guess is that there was an issue with the remote server when you tried? Can you try again and this time use `hg push review --verbose` ? The "verbose" flag will enable additional output that will help us debug whatever network/Mercurial issue that is happening. Otherwise that output so far looks correct.
Flags: needinfo?(jaws)
Okay, I've got a little bit further, perhaps it was like a temporary outage.
```
Jens@Jens-Laptop /C/nginx/html/projects/firefox
$ hg push review --debug
automatically setting Bugzilla API Key auth https://reviewboard-hg.mozilla.org
pushing to https://reviewboard-hg.mozilla.org/autoreview
using https://reviewboard-hg.mozilla.org/autoreview
sending capabilities command
using auth.autobmoapikey0.* for authentication
searching for appropriate review repository
sending listreviewrepos command
using auth.autobmoapikey0.* for authentication
redirecting push to https://reviewboard-hg.mozilla.org/gecko
sending capabilities command
using auth.autobmoapikey0.* for authentication
capabilities: streamreqs=generaldelta,revlogv1 changegroupsubset mozreviewrequir
es=bzapikeys,commitid,jsonproto,listreviewdata,listreviewrepos,proto1 httpmediat
ype=0.1rx,0.1tx,0.2tx unbundlehash pullreviews batch compression=zstd,zlib httph
eader=1024 lookup pushlog pushkey unbundle=HG10GZ,HG10BZ,HG10UN known bundle2=HG
20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%2Csha1%2Csha512%0Aerror%3Dabort%2Cuns
upportedcontent%2Cpushraced%2Cpushkey%0Ahgtagsfnodes%0Alistkeys%0Aphases%3Dheads
%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps branchmap getbundle mozreview=pub
lish,publishhttp,pullreviews,pushreview,submithttp reviewboard
query 1; heads
sending batch command
using auth.autobmoapikey0.* for authentication
searching for changes
all local heads known remotely
preparing listkeys for "phases"
sending listkeys command
using auth.autobmoapikey0.* for authentication
received listkey for "phases": 3473195 bytes
checking for updated bookmarks
preparing listkeys for "bookmarks"
sending listkeys command
using auth.autobmoapikey0.* for authentication
received listkey for "bookmarks": 7769 bytes
no changes found
preparing listkeys for "phases"
sending listkeys command
using auth.autobmoapikey0.* for authentication
received listkey for "phases": 3473195 bytes
submitting 1 changesets for review
using auth.autobmoapikey0.* for authentication
using auth.autobmoapikey0.* for authentication
http auth: user mozilla@jens-hausdorf.de, password *****************************
***********
using auth.autobmoapikey0.* for authentication
http auth: user mozilla@jens-hausdorf.de, password *****************************
***********
abort: HTTP Error 401: Unauthorized

```

But I created it and the api key exists in the mozreview board and in the config.
Flags: needinfo?(jaws)
My guess is that your API key wasn't copied correctly? gps, do you have any other ideas?
Flags: needinfo?(jaws) → needinfo?(gps)
I think it is something else, they are identical and I even trimmed the line at the end to prevent some weird behavior.
Okay, in the meantime, can you run `hg export -r. > 1442442.patch` ? This will create a file named 1442442.patch that you can upload to this bug and will include your author details as well as the commit message.
Flags: needinfo?(mozilla)
Attached patch 1442442.patchSplinter Review
Sure, here it is.
Flags: needinfo?(mozilla) → needinfo?(jaws)
Comment on attachment 8968615 [details] [diff] [review]
1442442.patch

Review of attachment 8968615 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!
Attachment #8968615 - Flags: review+
Flags: needinfo?(jaws)
Keywords: checkin-needed
Thanks for the patch Jens!

I've set the checkin-needed keyword on this bug. It should now get checked in to the mozilla-inbound repository very soon. We use mozilla-inbound as a place to land our code and make sure that the new code passes all tests before it gets merged to mozilla-central. After all the tests pass, it should get merged to mozilla-central about 6-12 hours later. We build two Nightly builds each day, so after it gets to mozilla-central it should show up in the next Nightly build within about 12 (or slightly more) hours.
Flags: needinfo?(gps)
Attachment #8965943 - Attachment is obsolete: true
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6b86063d7528
Add target=_blank to the releasenotes link so clicking on it will open in a new tab. r=jaws
Keywords: checkin-needed
Awesome! Hopefully it works next time with less trouble. :D

I'll check it once I receive a new build and hopefully can resolve it as `Fixed`. :)
https://hg.mozilla.org/mozilla-central/rev/6b86063d7528
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
(In reply to Jens Hausdorf from comment #25)
> Awesome! Hopefully it works next time with less trouble. :D
> 
> I'll check it once I receive a new build and hopefully can resolve it as
> `Fixed`. :)

Thanks! Bugs get automatically set to "resolved-fixed" when their patches are merged to the mozilla-central repository. After you confirm that it works you can set the bug to "verified-fixed", though you might not be able to if you don't have the edit-bugs permission on your account (I think?). Anyways, you could always comment here that the issue is now verified by you. Thanks!
You need to log in before you can comment on or make changes to this bug.