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)
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)
1.47 KB,
patch
|
jaws
:
review+
|
Details | Diff | Splinter Review |
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
Comment 1•6 years ago
|
||
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)
Comment 2•6 years ago
|
||
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)
Comment 3•6 years ago
|
||
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
Comment 4•6 years ago
|
||
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)
Updated•6 years ago
|
Mentor: sfoster, jaws
Keywords: good-first-bug
Comment 6•6 years ago
|
||
(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
Comment 7•6 years ago
|
||
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)
Updated•6 years ago
|
Assignee: trimeister.tran → nobody
Status: ASSIGNED → NEW
Assignee | ||
Comment 9•6 years ago
|
||
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)
Comment 10•6 years ago
|
||
Hi Jens, yes you may work on this. I'll assign it to you when you attach a patch. Thanks!
Flags: needinfo?(jaws)
Assignee | ||
Comment 11•6 years ago
|
||
Attachment #8965943 -
Flags: review+
Assignee | ||
Comment 12•6 years ago
|
||
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 13•6 years ago
|
||
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+
Updated•6 years ago
|
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Flags: needinfo?(jaws)
Assignee | ||
Comment 14•6 years ago
|
||
Okay, I'll try to set it up now. Thanks for the feedback.
Assignee | ||
Comment 15•6 years ago
|
||
``` 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)
Comment 16•6 years ago
|
||
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)
Assignee | ||
Comment 17•6 years ago
|
||
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)
Comment 18•6 years ago
|
||
My guess is that your API key wasn't copied correctly? gps, do you have any other ideas?
Flags: needinfo?(jaws) → needinfo?(gps)
Assignee | ||
Comment 19•6 years ago
|
||
I think it is something else, they are identical and I even trimmed the line at the end to prevent some weird behavior.
Comment 20•6 years ago
|
||
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)
Comment 22•6 years ago
|
||
Comment on attachment 8968615 [details] [diff] [review] 1442442.patch Review of attachment 8968615 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!
Attachment #8968615 -
Flags: review+
Updated•6 years ago
|
Flags: needinfo?(jaws)
Keywords: checkin-needed
Comment 23•6 years ago
|
||
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)
Updated•6 years ago
|
Attachment #8965943 -
Attachment is obsolete: true
Comment 24•6 years ago
|
||
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
Assignee | ||
Comment 25•6 years ago
|
||
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`. :)
Comment 26•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6b86063d7528
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox61:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
Comment 27•6 years ago
|
||
(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!
Updated•6 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•