New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 56 users

Issue metadata

Status: WontFix
Owner:
User never visited
Closed: Jul 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

Blocked on:
issue 129917



Sign in to add a comment

Poor user experience when accessing link that is an RSS feed

Project Member Reported by rdsmith@chromium.org, May 8 2012 Back to list

Issue description

Version: 20.0.1123.4
OS: Mac OS X 10.7.3

What steps will reproduce the problem?
1. Visit http://codereview.chromium.org/rss/closed/rdsmith
2. Profit!  (Or not :-{)

What is the expected output? What do you see instead?

I expect to see some text or some relevant information for the information stored there.  Instead I see a window saying "Which service should be used for viewing?" with a link to the chrome web store to under "Find more services by visiting the chrome web store."  

Please use labels and text to provide additional information.

My best guess after some thought is that chrome realized that the link was an RSS feed, tried to look up an extension or app that could display an RSS feed, didn't find one, and punted the user to the store to find a good app.  But:
* It wasn't at all clear that that was what was happening from the pop up; I had absolutely no clue what was meant by "What service should be used for viewing?"
* When I followed the link to the web store, it didn't point me at RSS reader apps (which would have produces an "Aha!"), it just linked to the main store.

I'm *sure* there's a better UE around here somewhere.  (Note that I, with my very specialized requirements, would have been happy with a text/plain display.)

 
Cc: kalman@chromium.org jhawkins@chromium.org
Is this a webintents feature?  I haven't seen it before; opening that link for me just downloads the RSS feed.
Owner: gbillock@chromium.org
Status: Assigned
@kalman: It would make sense that it was webintents, but I haven't intentionally configured anything WRT webintents in my browser.  Did you try it with the same Chrome version I did?

Labels: -Pri-2 -Feature-Apps -Feature-Extensions Pri-1 Mstone-21 Feature-WebIntents Review-UI
Greg, we need to figure out that the picker is empty in this case and offer the chance to view or download the RSS file.  Need verification from UI leads though.
Cc: groby@chromium.org
 Issue 130015  has been merged into this issue.
Blockedon: 129917
Noticed a few Google feeds worked as before. Examined the HTTP response and noticed the main difference was the HTTP header:

X-content-type-options: nosniff

Adding this to your HTTP responses seems to prevent this behaviour in Chrome 20.
It looks like this is happening in current beta, so changing current mstone.
Labels: -Mstone-21 Mstone-20
Also tempted to mark this a regression as the behavior has changed from 19-to-20. 
Cc: jeffreyc@chromium.org
There are now apps that support exactly this behavior, but there's a CWS bug that's preventing them from appearing.

Ultimately, the desired behavior is to support apps that'll show feed resource types in a more helpful way than a wall of XML text. (See  bug 33181 ). Those are coming, as well as providing developers who need to see XML text a way to still do so.
Labels: -Type-Bug Type-Regression
Is this going to be fixed for 20? This seems like an undesirable behavior regression. I get a blank box with no installation option.
I'm seeing this in 20.0.1132.21 on the mac for all of the feeds on http://www.miramax.com
Labels: ReleaseBlock-Beta
Labels: -ReleaseBlock-Beta ReleaseBlock-Stable
gbillock@: any updates?
This is a bug in CWS. It should be fixed and pushed by Monday, June 11.

If it is not so fixed, I will revert the new policy, and need to merge that patch.

Comment 18 by jwin...@gmail.com, Jun 12 2012

@gbillock This doesn't look fixed, can you back it out? 
The fix should be live today.
 Issue 131956  has been merged into this issue.
Note: to see how this is intended to work, you can install this app: https://chrome.google.com/webstore/detail/oceapojkdgeophkjdijkpbjifdnfimdh

It handles the MIME type for Atom/RSS and displays the contents very nicely. This is a developer-focused app -- support by feed reader apps will provide a much nicer end-user experience than what we have now, and that's what we're focused on with the new behavior.

See http://code.google.com/p/chromium/issues/detail?id=84 and http://code.google.com/p/chromium/issues/detail?id=33181
Cc: pavanv@chromium.org
pavanv@ clicked on www.techcrunch.com/feed/ twice on 21.0.1171.0 and it crashed. This happened in Windows and not reproducible in Mac.

other interesting stuff that I observed was a blank popup with a link to "More suggestions" which takes you to chrome web store that shows no results. This is again in 21.0.1171.0, windows 7.

http://crash.corp.google.com/reportdetail?reportid=d1d98321d62fad02

Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_READ @ 0x00000004 )

0x6b924baa	 [chrome.dll]	 - web_intents_registry.cc:194	
WebIntentsRegistry::OnWebDataServiceRequestDone(int,WDTypedResult const *)
0x6aeaf87d	 [chrome.dll]	 - web_data_service.cc:606	
WebDataService::RequestCompleted(int)
0x6aa8a8ac	 [chrome.dll]	 - bind_internal.h:1254	
base::internal::Invoker<2,base::internal::BindState,void (IPC::SyncChannel::SyncContext *,int),void (IPC::SyncChannel::SyncContext *,int)>,void (IPC::SyncChannel::SyncContext *,int)>::Run(base::internal::BindStateBase *)
0x6aa6f990	 [chrome.dll]	 - message_loop.cc:465	
MessageLoop::RunTask(base::PendingTask const &)
0x6aa6dece	 [chrome.dll]	 - message_loop.cc:654	
MessageLoop::DoWork()
0x6abf6312	 [chrome.dll]	 - message_pump_win.cc:238	
base::MessagePumpForUI::DoRunLoop()
0x6aa6da5f	 [chrome.dll]	 - message_loop.cc:419	
MessageLoop::RunInternal()
0x6ae981a6	 [chrome.dll]	 - message_loop.cc:770	
MessageLoopForUI::RunWithDispatcher(base::MessagePumpDispatcher *)
0x6ae97d57	 [chrome.dll]	 - chrome_browser_main.cc:1909	
ChromeBrowserMainParts::MainMessageLoopRun(int *)
0x6ae97abf	 [chrome.dll]	 - browser_main_loop.cc:444	
content::BrowserMainLoop::RunMainMessageLoopParts()
0x6ae97a28	 [chrome.dll]	 - browser_main_runner.cc:98	
`anonymous namespace'::BrowserMainRunnerImpl::Run()
0x6aad2f02	 [chrome.dll]	 - browser_main.cc:21	
BrowserMain(content::MainFunctionParams const &)
0x6aa678c2	 [chrome.dll]	 - content_main_runner.cc:371	
content::RunNamedProcessTypeMain(std::basic_string,std::allocator > const &,content::MainFunctionParams const &,content::ContentMainDelegate *)
0x6aa67849	 [chrome.dll]	 - content_main_runner.cc:627	
content::ContentMainRunnerImpl::Run()
0x6aa5a25e	 [chrome.dll]	 - content_main.cc:35	
content::ContentMain(HINSTANCE__ *,sandbox::SandboxInterfaceInfo *,content::ContentMainDelegate *)
0x6aa5a1ea	 [chrome.dll]	 - chrome_main.cc:28	
ChromeMain
0x01366357	 [chrome.exe]	 - client_util.cc:423	
MainDllLoader::Launch(HINSTANCE__ *,sandbox::SandboxInterfaceInfo *)
0x01365556	 [chrome.exe]	 - chrome_exe_main_win.cc:31	
RunChrome(HINSTANCE__ *)
0x013655c1	 [chrome.exe]	 - chrome_exe_main_win.cc:47	
wWinMain
0x013bda42	 [chrome.exe]	 - crt0.c:275	
__tmainCRTStartup
0x76933399	 [kernel32.dll]	 + 0x00013399]	
BaseThreadInitThunk
0x775b9ef1	 [ntdll.dll]	 + 0x00039ef1]	
__RtlUserThreadStart
0x775b9ec4	 [ntdll.dll]	 + 0x00039ec4]	
_RtlUserThreadStart
 Issue 126411  has been merged into this issue.

Comment 24 by kareng@google.com, Jun 13 2012

 Issue 132406  has been merged into this issue.
The work to fix this is in the chrome web store, and is slated to land Monday. Decision is wait until then and roll back the policy if needed.

Comment 26 by ddrew@chromium.org, Jun 14 2012

Labels: OS-All
I just tried on Monday, June 18th and the bad behavior still exists. It seems like this should be more robust to the Web Store's state anyway.
cbentzel: See the blocking bug,  issue 129917 .
Cc: dharani@chromium.org
We're getting too close to the wire, and I'm going to revert r133456 on M20. We should be ready for this on M21, but there's too much unpredictability at this point to leave it in place.
sounds good to me! Please go ahead and revert the change. thanks!

Comment 31 by glen@chromium.org, Jun 18 2012

Labels: -Review-UI
(label removal - the new intents picker UI has a provision for save)
Labels: -Mstone-20 -ReleaseBlock-Stable Mstone-21
As discussed in email, this will be targeted to M21.
 Issue 133475  has been merged into this issue.
Blockedon: -chromium:129917 chromium:129917
Status: WontFix
Support for viewing XML raw is now available in the store. Closing this as wontfix since no code is landing.
 Issue 46489  has been merged into this issue.

Comment 36 by Deleted ...@, Aug 5 2012

This just started happening to me.  I used to be able to view RSS/XML in the browser which was very useful.  All of a sudden (some time int he last 48 hours) Chrome started showing me that "services" alert and I am no longer able to just "See" the RSS.   Horrible!
Viewing raw RSS XML in the browser is of very little use to the majority of users. For web developers for whom this is useful, there are apps in the Chrome Web Store which provide that functionality. See  bug 33181  for instance.

Comment 38 by math...@qiwi.be, Aug 6 2012

As mentioned in  issue 126411  (which was closed as a duplicate even though it was posted before this issue), it should be possible to view the source of XML feeds in the browser. If not by entering the URL, prepending `view-source:` to the URL should work. Could that be a potential solution/workaround for developers?

Alternatively, perhaps a setting in the DevTools could enable viewing XML files.
See https://chrome.google.com/webstore/detail/oceapojkdgeophkjdijkpbjifdnfimdh which is a Chrome web store app that will enable you to view raw XML. (And in a nicer layout than the existing presentation.)
X'ing out of the dialog is a clear sign the user isn't interested in the CWS options. If they decide that, they are met with a blank page and a blank URL bar.

Instead of this dead-end, can we display the XMLViewer in this scenario?
paulirish: Long-term we need to expose the browser as a service (pre-registered of course).  Once the user clicks on this, and assuming the user does not decide to choose another service, the behavior should be the same as before the introduction of Intents in this flow.
To me canceling the dialog is a clear sign the user clicked on the link in error, and just wants out. Closing the tab seems like the right back-off for this case.

I completely understand that web developers want to be able to view the raw feed XML, but the fact that Chrome used to display that for feed links wasn't useful to the majority of users.

The power of web intents is that developers who want to see raw XML can use an app enabling them to do that, and end users who want to view the contents of the feed and subscribe to it can do that using the tool of their choice. That's the whole point. :-)

Comment 43 by aiiane@google.com, Aug 7 2012

Why should an external app be required for something that the browser already is entirely capable of doing?
aiiane: See comment 41.
 Issue 141122  has been merged into this issue.
Cc: vivianz@chromium.org anan...@chromium.org gbillock@chromium.org
 Issue 140233  has been merged into this issue.
 Issue 140233  has been merged into this issue.

Comment 48 by aiiane@google.com, Aug 7 2012

jhawkins: Yes, I was agreeing with comment 41. :)

Comment 49 by aiiane@google.com, Aug 7 2012

Also note that per merged-in bug, view-source: doesn't seem to work properly for feed urls with a content-type other than text/*.
The use of "Feed Intent Viewer" is not really a solid solution. Once the app takes over you are no longer able to manipulate the feed URL. Something that developers generally tend to do when trying to work with feeds.
That's a good feature. The viewer source is here: http://code.google.com/p/feed-intent-viewer/ I know that the author is actively interested in this feature, so if you write a patch I think it'll be well received.
I agree with #50. Keeping the current behavior of being able to view the XML directly in the browser is a feature too many of us use to just throw away.  Make it an additional option at the bottom of all the available intents.

Also note that, currently, disabling web-intents via "wrench->Privacy->Content Settings->Web Intents" results in very broken behavior whereby chrome automatically downloads the XML without prompting.

Comment 53 by m...@mshapiro.net, Aug 8 2012

I am very disappointed with this change.  The feed intent viewer is terrible for web development, as it seems to be caching the xml and I can't find a way to refresh it.  Furthermore, it adds an extra layer of complexity to what should be a simple process.  I should be able to check a button on the intents menu to specifically state that I do not wish to open this with a plugin but instead intend to open it with the browser itself.
Cc: -kalman@chromium.org

Comment 55 by Deleted ...@, Aug 10 2012

Seeing this issue despite having Foxish live RSS 3.7 installed.
When selecting certain feeds, the "reader picker" shows up.
I already have a reader ! Happening (amongst many others) at http://www.athensnews.gr/rss
using Chrome Version 21.0.1180.75 on Ubuntu 11.10 Gnome Classic.

Comment 56 by zekin...@gmail.com, Aug 10 2012

Very disapointed by this new behavior.
Viewing XML file directly in the browser is really an obligatory option for me.
Hope it will be fixed.

Comment 57 by Deleted ...@, Aug 10 2012

Same boat here.

Another option we have lost is using CSS and/or XSLT to format the XML. On other browsers you can attatch style-sheets to rss feeds to format them nicely, but Chrome always tries to download. 

Comment 58 by Deleted ...@, Aug 11 2012

I would like to be able to see the raw xml in my browser.  I don't know what's going on but the current behavior is problem for me.  I'm constantly asked by people what's wrong with their RSS and downloading is completely un-useful.  Furthermore, when it downloads it doesn't expose the URL, so I can't copy the URL and use it to send to someone so they can stick it in their iTunes or whatever.

In my opinion, the browser should never download a file like this as a default behavior.  What's the average user going to do with it?

I like the Firefox default behavior - render the page in the browser so it looks like a regular webpage to virtually everyone and then let me view source to see the source.  And I should not have to add extensions to support this default behavior.

Hope whoever you are at chromium.org are listening.


Comment 59 by mblak...@gmail.com, Aug 13 2012

Yeah, I bump this. Really bad and has somehow killed the extentions that previously read all of my XML feeds notably XML Tree and XML Viewer. 

Comment 60 by Deleted ...@, Aug 13 2012

Bump... very annoying. 

Comment 61 by mattl...@gmail.com, Aug 13 2012

I think the argument in Comment 50 is very compelling. If I need to add or change GET parameters, even if I have installed the proper web intents, I need to copy the URL before I submit it and then paste it and edit it again. Additionally, if I open a feed in a background tab (Alt+Click) it directly downloads without the option to view it using any available intents. This is a very poor UX and a great step backward, IMO...
 Issue 141088  has been merged into this issue.

Comment 63 by Deleted ...@, Aug 14 2012

The status says it all. They are not going to fix this one. So anyone who wants to view the feeds without being downloaded will just have to get some new browser.

This issue is really annoying, but if the majority of users expect fancy views and love using plugins for everything. Well, there is really nothing to be said or done.
Well, since it was closed on July 3rd, before many of the comments regarding Web Intents and lack of functionality provided by the Chrome apps, I have high hopes that the developers will reconsider adding in the optional functionality of directly viewing RSS feeds.
Even with the plugin from comment 21, Chrome Version 21.0.1180.77 still downloads the feed in the background before the intents window opens. At this rate my downloads folder will be filled with a hundred files called "download.rss" by the end of the week. How is this not seen as a bug by the developers?

Comment 66 Deleted

Comment 67 by Deleted ...@, Aug 15 2012

This is typical RSS feed hijacking by the web browser and has been a problem in one form or another for many years. Browser makers seem to think that they know how to handle the "special case" of RSS flavored XML files and they always get it wrong when they try to add interfering design. Chrome actually had it right before this... Chrome ignored RSS and just loaded the data appropriately. 

My biggest complaint is how it ignores the XSL stylesheet processing instruction which should without a doubt take precedence over the browser's handling of the document. The stylesheet reference is there to tell the browser what to do and is a w3c standard. Ignoring this is poor design and an intentional bug, especially in its current design state.

Understanding the motives and intentions, A compromise is surely still on the table, right? 
I am aware of hacky workarounds but it would be nice for once to have a development and product team actually discuss this issue in a reasonable thoughtful manner. Its not just about what developers want and the increasing focus on consumer-level web browser product. More careful and less hasty modifications needs to be the norm and this issue does not demonstrate that. 

#65: yes, that's a problem with a fix in progress.
So based on comment #41, can we see this issue marked as "open" or at least no longer "wontfix"?
This is a major issue for developers in the RIGHT NOW. Chome is a fantastic browser and has previously been a joy to work in. Some level of UI MUST be implemented. Web intents be damned. I shouldn't need a plugin, and I certainly don't want a browser to decide to download ANY kind of file without me explicitly telling it to. You're not apple, you're google. "Don't be evil" and let me make my own decisions on how to interact with the information comming through our wires. As stated above this breaks existing extensions. I'm sorry that most users don't need to see XML but Frankly most users don't even know what they are. 

please realize that web applications and sites will work better in your browser if you please the suite of people building and maintaining these apps and sites.

Comment 71 by math...@qiwi.be, Aug 16 2012

A proposed solution in two acts:

1. When such feed URLs are prefixed with `view-source:`, there’s no doubt that the end user wants to view the source code instead of opening the Web Intents handler. So, suppress the “Which service should be used for viewing this feed?” prompt in these cases.
2. Expose Chrome’s built-in support for the `view-source:` scheme as a Web Intents handler for such feeds. 

That way, all problems are solved at once:

* Developers can still easily view source code of feeds after a trivial one-time setup.
* No third-party Chrome extensions required.
I've updated the Feed Intent Viewer app (https://chrome.google.com/webstore/detail/oceapojkdgeophkjdijkpbjifdnfimdh) based on feedback from this thread. In version 1.1 it:
- Displays the feed URL (and allows it to be modified)
- Re-fetches the feed from the server when the page is reloaded

If you already have it installed, you can force an immediate update by going to chrome://extensions, enabling developer mode, and pressing the "Update extensions now" button.

Comment 73 by mgaba@chromium.org, Aug 17 2012

Thanks to everyone for the feedback. We have been actively discussing a better way of handling RSS feeds.

We originally marked this issue as WontFix because the vast majority of our users do not interact with RSS feeds the way the developers in this thread interact with RSS. For most users, viewing raw XML is not a good user experience. We believe giving these users the choice to select an RSS handling service via Web Intents is a good solution to this problem. 

Having said that, we are actively working toward a solution that provides an outstanding experience for our developers and casual users alike. In the meantime, there are Web Intents services that you can install via the Chrome Web Store that will provide most of the desired functionality that has been expressed in this thread. (Feed Intents Viewer is a great option: https://chrome.google.com/webstore/detail/oceapojkdgeophkjdijkpbjifdnfimdh)

Take care, and I will keep this thread up-to-date as our conversation progresses into actionable bugs. 
If web intents are to be used to handle RSS within chrome then it either needs to have a default intent handler or it needs to prompt the user to use an intent to handle the feed. RSS is so ubiquitous on the web that users will become confused about "what" they've just downloaded if there isn't a default intent to handle the file.

Comment 75 by umo1...@gmail.com, Aug 17 2012

Possibly the most frustrating UX change in Chrome yet.  Bump.
Few more changes like this and I go back to that slow FF.
If sb. say that XML view is not useful for may people that Chrome is not browser for me, because I'm not the many people. Does anybody really think that that horrible popup is more useful than RAW XML view that has been there for many releases?
I agree.  I use several different content management systems and web
frameworks which publish content as RSS feeds.  Now, when users browse
those sites and click on the RSS link icon from within Chrome their browser
just downloads some random file like "Default.aspx" or "RSS.html" or
"RSS.php", etc.  it is very confusing for end users.  Earlier someone in
the conversation mentioned that this problem only affects developers, but I
disagree!  Us developers actually KNOW how to handle this situation and if
it ONLY affected us, we really probably wouldn't care.  But, in fact, we
are so angry about this change because of what it is doing to our END
USERS.... please take notice of this and know that our concerns lie with
how this experience affects our content users more than we care about how
it makes our development a little more difficult.... Thank you.
It might be a good idea to optionally allow extensions to hijack / override the web intents dialog. For example, I extensively use the excellent "XML Tree" extension (https://chrome.google.com/webstore/detail/gbammbheopgpmaagmckhpjbfgdfkpadb). If this extension had the ability to "claim" certain interactions away from web-intents, I would be a very happy developer.
Patrick, I do understand that you would like to see some new functionality,
but please be aware that this particular thread is dedicated to a known bug
currently affecting a large number of website and users.  You should
definitely open a new issue and start a conversation asking for the
functionality that you have mentioned.

Thank you!
Hi Will,

Good point, my comment is out of scope for this particular issue. I will open a new one. 
Patrick: extensions can quite readily be modified to be web intents services and handle the display of feed contents.
I'd like to just see the RSS feed in a normal Chrome tab, without any downloads or this new dialog window.  Thanks.
What is the current status on this issue?
The feed intent viewer app allows url manipulation (thanks Mihai!). There are code fixes in review for some of the edge cases we didn't account for (target=_blank was particularly bad --  bug 129784 ).
Does that mean comment #41 by jhawk no longer stands?
no
please remove this feature or at least let the user choose a preference. i just want to see the xml like i used to.

Comment 88 by Deleted ...@, Sep 17 2012

This is a real annoyance - it means I'm now breaking out a different browser to work with RSS.  Surely adding an option 'view raw RSS' wouldn't hurt?
 Issue 150627  has been merged into this issue.

Comment 90 by Deleted ...@, Oct 29 2012

End users on my site are complaining because they cannot subscribe to feeds. When they click on the standard RSS / Atom links, all they see is a popup dialog and an attempt to download a file with an unfamiliar extension (.webintents). I have even had a user notify me that my site tried to force them to download a virus.

This is clearly not an issue that only impacts developers, who can at least research and find ways around the annoyance. But local installations of extensions on my browser will not be of any help to end users, who will likely just become confused or irritated.

Please provide a solution that will make the end user experience more intuitive.
Project Member

Comment 91 by bugdroid1@chromium.org, Mar 9 2013

Labels: -Type-Regression -Area-UI -Mstone-21 -Feature-WebIntents Type-Bug-Regression Cr-UI-Browser-WebIntents Cr-UI M-21

Comment 92 by laforge@google.com, Jul 24 2013

Cc: -jeffreyc@chromium.org

Sign in to add a comment