Closed Bug 405944 Opened 17 years ago Closed 17 years ago

Security check livemark siteURI

Categories

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

defect

Tracking

()

VERIFIED FIXED
Firefox 3 beta3

People

(Reporter: philor, Assigned: dao)

References

()

Details

Attachments

(1 file)

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?
Blocks: 405927
Yeah, good catch.
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P3
Target Milestone: --- → Firefox 3 M11
Attached patch patch v1 (deleted) — Splinter Review
I can't test this currently because the dialog for creating the livemark isn't well-formed...
Attachment #294613 - Flags: review?(dietrich)
I've tested the patch successfully.
Comment on attachment 294613 [details] [diff] [review] patch v1 r=me, thanks
Attachment #294613 - Flags: review?(dietrich) → review+
Keywords: checkin-needed
Assignee: nobody → dao
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
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Flags: in-testsuite?
Dão, can you confirm the fix, please?
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 :)
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
(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.
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.
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
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: