maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Clicking on webcal:// link does nothing (not even an error dialog)|
|Product:||[Maemo Official Applications] Browser||Reporter:||Murray Cumming <murrayc>|
|Component:||User interface||Assignee:||unassigned <nobody>|
|Status:||RESOLVED FIXED||QA Contact:||browser-bugs|
SOFTWARE VERSION: (Settings > General > About product) EXACT STEPS LEADING TO PROBLEM: (Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message Connection Failed appears)) 1. Start the web browser 2. Navigate to http://live.gnome.org/TwoPointTwentynine 3. Click the "webcal schedule link" link. EXPECTED OUTCOME: 4. The Browser should either - Say that the webcal:// protocol is not supported. See https://bugs.maemo.org/show_bug.cgi?id=7889 or - Offer to subscribe the calendar application to that calendar. ACTUAL OUTCOME: - Nothing at all happens. REPRODUCIBILITY: (always, less than 1/10, 5/10, 9/10) Always EXTRA SOFTWARE INSTALLED: Lots from extras-testing and extras-devel OTHER COMMENTS: Long-press on this link doesn't bring up any context menu either, though it does for regular http:// links.
When clicking on the webcal link in internal version 2010.02-5 I get Unable to open. Address type not supported. webcal://www.gnome.org/start/unstable/schedule.ics I can confirm that nothing happens in 1.2009.44-1, hence this has probably been fixed in the meantime.
That isn't the resolution I would have liked. It should add it so you can view it.
firstname.lastname@example.org: If you want the calendar to support webcal: then you should try filing a bug against the calendar application not the web browser. Please note that in general adding support for entire features is not something that Nokia management likes to manage with a bug tracker, they've proposed that such requests be filed/managed in "Brainstorm", I suspect that might be http://maemo.org/community/brainstorm -- either way, your bug doesn't belong in the browser component, and we request that you not hijack other people's bugs. This bug has an expected result "4" which clearly accepts an error message as a valid possible outcome. We've actually done precisely what the reporter requested. This is rare, and I would hope the reporter is happy about it. Such cases should be framed and shown as examples of good bugs. The last thing we want in them is reopening for another purpose. A bug's life should be short and direct.
Okay, what you say is very reasonable, thanks.
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).