Closed Bug 395250 Opened 19 years ago Closed 18 years ago

Web Feed shows me a preview, option says to use Live Bookmark

Categories

(Firefox :: File Handling, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 3 beta1

People

(Reporter: stevee, Assigned: myk)

References

Details

(Keywords: regression)

Attachments

(1 file, 5 obsolete files)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007090602 Minefield/3.0a8pre ID:2007090602 1. New profile, start firefox 2. Go to http://news.bbc.co.uk 3. Click on RSS feed. Note you get a preview. 4. Tools > Options > Applications 5. Scroll down to Web Feed. Note that it says "Show me a preview and ask me.." 6. Click on Web Feed. Expected: - Drop down selection box should have "Show me a preview and ask me.." selected Actual: - Drop down selection box has "Live Bookmarks" as its selection.
Blocks: 377784
No longer depends on: 377784
I see this on Linux and Mac as well. Investigating.
Assignee: nobody → myk
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: --- → Firefox 3 M9
Attached patch patch v1: fixes problem (obsolete) — Splinter Review
The problem is that rebuildActionsMenu doesn't check alwaysAskBeforeHandling before selecting the item in the menu corresponding to preferredAction. alwaysAskBeforeHandling overrides preferredAction, so even if preferredAction is set to "Live Bookmarks" (as it is by default), when alwaysAskBeforeHandling is set to true (as it is by default), then we always ask the user what they want to do (which for feeds means showing them the preview page), so we should select the alwaysAskBeforeHandling item in the menu (which for feeds is the "Show me a preview..." item). In this patch, I make sure to always check alwaysAskBeforeHandling before selecting a menu item based on the value of preferredAction. Note that this doesn't yet matter for other types, but it will matter once we fix bug 395138 and start showing other types for which we always ask. Gavin: a better fix might be to create all the menu items first, then select the appropriate item at the end based on the values of alwaysAskBeforeHandling and preferredAction. That shouldn't be too hard to do, and it would make the code simpler overall. What do you think?
Attachment #279967 - Flags: review?(gavin.sharp)
(In reply to comment #2) > Gavin: a better fix might be to create all the menu items first, then select > the appropriate item at the end based on the values of alwaysAskBeforeHandling > and preferredAction. That shouldn't be too hard to do, and it would make the > code simpler overall. What do you think? I agree, setting the selected item at the end rather than as you're adding items to the menu would be clearer.
> I agree, setting the selected item at the end rather than as you're adding > items to the menu would be clearer. Ok, here's a patch that does it like that.
Attachment #279967 - Attachment is obsolete: true
Attachment #279997 - Flags: review?(gavin.sharp)
Attachment #279967 - Flags: review?(gavin.sharp)
No longer blocks: 377784
Depends on: 377784
Blocks: 377784
No longer depends on: 377784
Status: NEW → ASSIGNED
Priority: -- → P1
Keywords: regression
Gavin suggested on IRC that this would be better if we selected the selected item from the menuitem objects we created in the process of building the menu rather than by going back to the DOM to retrieve the object. Here's a patch that does it that way.
Attachment #279997 - Attachment is obsolete: true
Attachment #280542 - Flags: review?(gavin.sharp)
Attachment #279997 - Flags: review?(gavin.sharp)
Attached patch patch v4: unrotted (obsolete) — Splinter Review
Attachment #280542 - Attachment is obsolete: true
Attachment #281718 - Flags: review?(gavin.sharp)
Attachment #280542 - Flags: review?(gavin.sharp)
Requesting blocking-firefox3 for this Applications prefpane regression fix.
Flags: blocking-firefox3?
Attached patch patch v5: unrotted (obsolete) — Splinter Review
Attachment #281718 - Attachment is obsolete: true
Attachment #282809 - Flags: review?(gavin.sharp)
Attachment #281718 - Flags: review?(gavin.sharp)
Attachment #282809 - Flags: review?(gavin.sharp) → review+
Flags: blocking-firefox3? → blocking-firefox3+
It's easy to rot this patch, but fortunately the conflicts are simple to resolve (there aren't any functionality conflicts, just code being modified in the vicinity of the changes in this patch). Here's an up-to-date version that is the version I'll check in.
Attachment #282809 - Attachment is obsolete: true
Checking in browser/components/preferences/applications.js; /cvsroot/mozilla/browser/components/preferences/applications.js,v <-- applications.js new revision: 1.17; previous revision: 1.16 done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Long fixed but verified in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050904 Minefield/3.0pre.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: