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 15 users

Issue metadata

Status: Archived
Owner: ----
Closed: Sep 13
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug
KDE



Sign in to add a comment
link

Issue 109913: KDE file save dialog does not have the "save as full webpage" option

Reported by thestig@chromium.org, Jan 11 2012 Project Member

Issue description

With KDE, run Chrome and try to save a webpage. There should be an option to save the full webpage, just like there is with the GTK file dialog. I'm not sure if this is feasible. Will need to take a look at the kdialog options.
 

Comment 1 by thestig@chromium.org, Jan 11 2012

Not sure if this is feasible. kdialog doesn't seem to take multiple filters. I tried "foo\nbar" but that didn't work either. As such, we have no way of passing in the extension_description_overrides.

Comment 2 by mdm@chromium.org, Jan 11 2012

Hmm. I suppose we can probably use the GTK dialog in that case? That'd be kind of inconsistent, but I don't see how else to deal with it other than removing the KDE dialog support.

Comment 3 by skr...@gmail.com, Jan 12 2012

It seems most of the KDE community are happy with the KDE dialog despite this problem, so reverting to the GTK dialog by default won't be popular.  Could one put an option in the settings to revert to the GTK dialog with "save full webpage" support if one can't do this with kdialog?  Alternatively, putting "save full webpage" in the context menu/file menu would mean you'd only need a single filter in kdialog?

Comment 4 by skr...@gmail.com, Feb 5 2012

Any suggestions on how I can help get this bug resolved?

Comment 5 by mdm@chromium.org, Feb 6 2012

Recent versions should support using the GTK dialog instead of the KDE one if you set the NO_CHROME_KDE_FILE_DIALOG environment variable. If you are a programmer, you can try writing a patch that fixes the problem and upload it for review. Otherwise you'll have to wait until somebody gets to this issue.

Comment 6 by b7.10110...@gmail.com, Apr 28 2012

It seems best to me to make a feature request (and possibly a patch) for KDialog so that it did support multiple filters. Then just recommend the users to upgrade kdialog.

Comment 7 by b7.10110...@gmail.com, Apr 28 2012

I've created a KDE bug report and provided a simple patch. Here it is for anyone interested: https://bugs.kde.org/show_bug.cgi?id=298982

Comment 8 by mdm@chromium.org, Apr 30 2012

This KDE bug suggests a possible way to get KDialog to accept multiple MIME types; we should see if it will work for us. I don't have KDialog handy here so I'll have to check later.

https://bugs.kde.org/show_bug.cgi?id=295820

kdialog --getsavefilename $HOME "text/html application/x-webarchive"

Comment 9 by b7.10110...@gmail.com, Apr 30 2012

> kdialog --getsavefilename $HOME "text/html application/x-webarchive"
Yeah, this works, but the default filter appears to be "HTML document, web archive", which doesn't look too meaningful...

Comment 10 by phajdan.jr@chromium.org, Jan 3 2013

Labels: KDE

Comment 11 by b7.10110...@gmail.com, Jan 3 2013

BTW, this appears fixed in KDE 4.9 according to https://bugs.kde.org/show_bug.cgi?id=295820#c6 .
One can now use
kdialog --getsavefilename $HOME "type1\ntype2"

Comment 12 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Area-UI Cr-UI

Comment 13 by cjac...@gmail.com, Nov 19 2015

It's a issue exists several years.

The way chrome support kde dialog is by involking 'kdialog' command, for save file, it use 'kdialog --getsavefilename 'name' 'filter''.
Even 'kdialog' already patched to support multiple filters, but it's still not work.

The root cause is: 
1, It's not easy to add multiple filer as 'when save files, the file extensions is 'html' and happened multiple times'.

in 'save_package_file_picker.cc':

If 'can be saved as complete html', there is special treatment to add more 'file_type_info' to extra_extensions. but the 'file extension' is still 'htm/html'.
AddCompleteFileTypeInfo(&file_type_info, extra_extension);
save_types_.push_back(content::SAVE_PAGE_TYPE_AS_COMPLETE_HTML);

And in 'select_file_dialog_impl_kde.cc' 'SelectFileDialogImplKDE::GetMimeTypeFilterString', it use a set to hold file extionsions to avoid duplication.

  // We need a filter set because the same mime type can appear multiple times.
  std::set<std::string> filter_set;

Thus, the extra_extension information is ignored, but this issue can be easily fixed.

2,'kdialog' only return a 'filepath' used by chromium to save file, but chromium need to retrieve the 'file type index' to determine 'save only html' or 'save as complete page'.
For gtkdialog, since called via GTK API, it's easy to interact with the customized filters and filter index user choosed. but for 'kdialog' command, there is no way to do that, all chromium can get from kdialog is the 'filepath'.

So, in 'select_file_dialog_impl_kde.cc', there is a comment:

  if (listener_) {  // What does the filter index actually do?
    // TODO(dfilimon): Get a reasonable index value from somewhere.
    listener_->FileSelected(path, 1, params);

And above is the answer, and there is no easy way to get the 'reasonable index value' up to now. Maybe, if 'kdialog' support 'dbus involking' in future, it may solve the problem.


Conclusion:
To fix this issue correctly, it requires:
1, kdialog support multiple filter. (already done)
2, chromium pass 'multiple filter' to 'kdialog'. (easy to do)
3, chromium can retrieve 'file type index' from 'kdialog'. (difficult, at least this time).

Since most users prefer to 'save complete page' than 'save only html', what I choose to do is 'If page can be saved as 'complete html' and 'kdialog' used and 'Not forced to use gtk dialog'', then let's default to 'save page as complete html' when savetype equal to 'content::SAVE_PAGE_TYPE_AS_ONLY_HTML'.

The patch attached below.
force-chromium-save-html-as-complete-page-when-use-kde-and-not-force-to-gtkdialog.patch
2.1 KB Download

Comment 14 by sundoul...@gmail.com, Sep 12 2016

Any chance this patch will get added to official builds?

Comment 15 by thestig@chromium.org, Sep 21 2016

Cc: thomasanderson@chromium.org
We don't take patches here. One needs to follow the process at https://www.chromium.org/developers/contributing-code

Comment 16 by sheriffbot@chromium.org, Sep 22 2017

Project Member
Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 17 by thestig@chromium.org, Oct 4 2017

Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)
It is unlikely we will ever take patches here, so if someone wants to fix this, submit patches the proper way.

Comment 18 by timbrown@chromium.org, Nov 14 2017

Cc: timbrown@chromium.org
 Issue 728514  has been merged into this issue.

Comment 19 by robliao@chromium.org, Sep 13

Status: Archived (was: Available)
Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!

Comment 20 by robliao@chromium.org, Sep 13

Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!

Sign in to add a comment