Closed
Bug 405944
Opened 17 years ago
Closed 17 years ago
Security check livemark siteURI
Categories
(Firefox :: Bookmarks & History, defect, P3)
Firefox
Bookmarks & History
Tracking
()
VERIFIED
FIXED
Firefox 3 beta3
People
(Reporter: philor, Assigned: dao)
References
()
Details
Attachments
(1 file)
(deleted),
patch
|
dietrich
:
review+
|
Details | Diff | Splinter Review |
From bug 405927, STR:
1. Edit - Preferences, Applications tab, find the "Web Feed" row and change it
to "Live Bookmarks in Firefox"
2. Load data:text/html,<link%20rel="feed"%20href="http://mozilla.org/news.rdf">
3. There's now a white-on-orange icon in the addressbar - click it, and in the
dialog that comes up choose to "Create in: Bookmarks Toolbar" and click "Add"
4. You now have a bookmarks folder on the toolbar, named "Mozilla Dot Org", in
which we will refuse to create bookmark items from the feed items if they have
a data: URI for a link, but which has an item at the bottom, with the label
'Open "Mozilla Dot Org"' which links to the page where you added the feed, in
this case that data: URI.
Unless I'm missing something, we only set siteURI in nsLivemarkService.js, in _createFolder and in setSiteURI - having _createFolder call setSiteURI, and having setSiteURI call CheckLoadURI, ought to cover it.
Flags: blocking-firefox3?
Comment 1•17 years ago
|
||
Yeah, good catch.
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P3
Target Milestone: --- → Firefox 3 M11
Assignee | ||
Comment 2•17 years ago
|
||
I can't test this currently because the dialog for creating the livemark isn't well-formed...
Attachment #294613 -
Flags: review?(dietrich)
Assignee | ||
Comment 3•17 years ago
|
||
I've tested the patch successfully.
Assignee | ||
Updated•17 years ago
|
Comment 4•17 years ago
|
||
Comment on attachment 294613 [details] [diff] [review]
patch v1
r=me, thanks
Attachment #294613 -
Flags: review?(dietrich) → review+
Assignee | ||
Updated•17 years ago
|
Keywords: checkin-needed
Updated•17 years ago
|
Assignee: nobody → dao
Comment 5•17 years ago
|
||
Checking in toolkit/components/places/src/nsLivemarkService.js;
/cvsroot/mozilla/toolkit/components/places/src/nsLivemarkService.js,v <-- nsLivemarkService.js
new revision: 1.32; previous revision: 1.31
done
Reporter | ||
Updated•17 years ago
|
Flags: in-testsuite?
Comment 6•17 years ago
|
||
Dão, can you confirm the fix, please?
Reporter | ||
Comment 7•17 years ago
|
||
Oh, come on, there's exhaustive STR in comment 0: if you see an |Open "Mozilla Dot Org"| item at the bottom by open in tabs, we lose, if not, we win.
Dão can't be spending time pointlessly verifying that he still thinks he fixed his bug, he needs to be working on the automated testcase he should have had to do before getting review or checking in :)
Comment 8•17 years ago
|
||
Verified in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008010304 Minefield/3.0b3pre.
Phil, a little less attitude next time will go a long way, especially since we don't know each other.
As the reporter, you should have verified this anyway when it was fixed if you are inclined to tell people what they should be doing with their time.
The steps were not entirely clear in the original comment but I puzzled them out.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 9•17 years ago
|
||
(In reply to comment #8)
> As the reporter, you should have verified this anyway
Could you please point me toward the instructions that tell me that? If I've missed that rule over the last four years, I may well have missed others in the same document - I've certainly missed seeing anything that explains how it might make sense to have the developer who said it was fixed also verify that it was fixed.
Comment 10•17 years ago
|
||
Yes, it must be entirely outside the realm of reason for the reporter of a bug to be the one who verifies that it is fixed. No one ever does that nor is it accepted practice (right?). Instead, the reporter should jump on other people who are simply trying to see that the bug is verified so it is known not to be an issue and tell them what they should be doing because that is less work than verifying his own issue.
I found your steps unclear and I have many many bugs to go through so I attemppted to take a quick out. Dao had verified his fix before he checked it in. It was reasonable to ask him (since no one else was stepping up) to check the fix in an actual build since it seemed likely that he understood the issue better than I, who felt your repro steps were unclear.
By all means, continue to be snarky though. First impressions and all that. I'm done with this bug and won't be replying further since I have verified it. If you want to continue to whinge at me, by all means, take it to e-mail.
Comment 11•15 years ago
|
||
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".
In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body contains places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.
Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.
Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Reporter | ||
Updated•14 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•