Closed Bug 589543 Opened 14 years ago Closed 14 years ago

RSS does not show subscribe section anymore

Categories

(Firefox Graveyard :: RSS Discovery and Preview, defect)

defect
Not set
major

Tracking

(blocking2.0 beta5+)

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta5+

People

(Reporter: nightstalkerz, Assigned: philor)

References

()

Details

(Keywords: regression, smoketest)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100822 Minefield/4.0b5pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100822 Minefield/4.0b5pre When viewing a RSS feed, you cannot subscribe anymore as the subscribe controls are hidden Reproducible: Always Steps to Reproduce: 1. Go to the URL 2. Attemp to subscribe to the RSS feed Actual Results: The subscribe controls are hidden. See screenshot http://img832.imageshack.us/i/55429576.png/ Expected Results: The subscribe controls are visible From error console: Error: XML or text declaration not at start of entity Source File: jar:file:///C:/Program%20Files/Minefield/omni.jar!/chrome/browser/content/browser/feeds/subscribe.xml Line: 37, Column: 1 Source Code: <?xml version="1.0" encoding="utf-8"?> and Error: uncaught exception: [Exception... "'[JavaScript Error: "this._getUIElement("handlersMenuPopup") is null" {file: "jar:file:///C:/Program%20Files/Minefield/omni.jar!/components/FeedWriter.js" line: 1158}]' when calling method: [nsIFeedWriter::close]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "JS frame :: chrome://browser/content/feeds/subscribe.js :: SH_uninit :: line 55" data: yes]
Status: UNCONFIRMED → NEW
blocking2.0: --- → beta5+
Ever confirmed: true
Keywords: regression
Flags: in-testsuite?
Flags: in-litmus?
OS: Windows 7 → All
Hardware: x86 → All
It's already in-litmus, in fact to the extent they still exist it's a smoketest, since there's a "You should be taken to a page which has UI at the top with a light yellow background that allows you to select the feed reader you want to use." step in https://litmus.mozilla.org/show_test.cgi?id=10126
Assignee: nobody → philringnalda
Flags: in-litmus?
Keywords: smoketest
Version: unspecified → Trunk
Attached patch Fix v.1 (deleted) — Splinter Review
Attachment #468192 - Flags: review?(gavin.sharp)
Comment on attachment 468192 [details] [diff] [review] Fix v.1 Seems like the test would be better off as a browser-chrome test, but I won't be picky. (Are the enablePrivilege calls really needed?)
Attachment #468192 - Flags: review?(gavin.sharp) → review+
It's a miserable document to work with, and maybe it would have been less miserable from browser-chrome, even though it's really more content than chrome. UniversalXPConnect (or at least something more powerful than UniversalBrowserRead) is needed to avoid "Security Manager vetoed action arg 0 [nsIDOMDocumentXBL.getAnonymousElementByAttribute]", and you're right, I didn't need UniversalBrowserRead for whatever I'd first added it for, with that. http://hg.mozilla.org/mozilla-central/rev/ed7e9896d4cb
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: