Created attachment 55959 [details] Sample HTML File with a small Table One cannot open HTML in Calc any longer instead they open in Writer/Web. How to reproduce: 1. Download attached sample HTML document. 2. Start Calc, choose File open 2.a under File type choose "HTML Document (OpenOffice.org Calc) (*.html;*.htm)" 2.b select document and OK 3. Document opens in Writer/Web Expected: document should be opened in Calc This worked as expected in prior Versions (OOo 3, LO 3.4.5).
I reproduced this pb on Master and 3.5 branch. (PC Debian x86-64)
This is not a Windows specific change. Modified OS to All. I'm not sure this is a bug. If the file is HTML it makes sense that it is opened in the HTML editor. Unless a rule is setup that if an HTML file only contains a table, then open in Calc... Does that make sense? You can still open the HTML file as a spreadsheet by opening Calc and choosing Insert, Sheet from file and selecting the HTML file you know only contains a table.
@Pedro: > Unless a rule is setup that if an HTML file only contains a table, then open in > Calc... Does that make sense? Partly, please see point 2.a in OP: 2.a under File type choose "HTML Document (OpenOffice.org Calc) (*.html;*.htm)" This option (File type) is specifically there to open the file in Calc. Notice also that this bug is a regression and it worked as described before. It /could/ be that this is a knew expected behavior in 3.5, but I highly doubt that because the File Type option ("HTML Document (OpenOffice.org Calc) (*.html;*.htm)") wouldn't make any sense then. > You can still open the HTML file as a spreadsheet by opening Calc and choosing > Insert, Sheet from file and selecting the HTML file you know only contains a > table. Yes, that would be a good work around.
Reducing importance to major.
@Cor Nouws Please take a look.
confirmed - was fine in 3.4.5 thanks for testing & reporting!
Technically this is not a regression, since we never properly handled this at filter type detection level. The fact that it seems to have worked in 3.4.x is purely due to nothing but luck. E.g. this never worked for me even in 3.3 or 3.4. Internally, the algorithm that picks the app to open has no idea from which app the user is opening a given file. In HTML's case, candidates are writer/web or calc. Which ever app happens to be stored first in boost::unordered_map gets picked. And since the container doesn't guarantee the order, which app gets picked when there are multiple candidate apps is anyone's guess. The current workaround is to select "HTML Document (OpenOffice.org Calc)" or "Web Page Query (OpenOffice.org Calc)" (hmm OOo is still used there...) as the file type when opening the HTML file from File - Open. Or, do as Pedro suggested. Yes, this is a UI bug and we need to fix this some day, but it's not a regression. Removing the regression keyword.
Hi Kohei, thanks for the explanation... (In reply to comment #7) > The current workaround is to select "HTML Document (OpenOffice.org Calc)" or > "Web Page Query (OpenOffice.org Calc)" (hmm OOo is still used there...) as the > file type when opening the HTML file from File - Open. That is what Famo wrote in his point 2 and what I tested and found *not* to work > Removing the regression keyword. Revering that, sorry.
(In reply to comment #8) > (In reply to comment #7) > > The current workaround is to select "HTML Document (OpenOffice.org Calc)" or > > "Web Page Query (OpenOffice.org Calc)" (hmm OOo is still used there...) as the > > file type when opening the HTML file from File - Open. > > That is what Famo wrote in his point 2 and what I tested and found *not* to > work > Yes, exactly. This is what the bug is all about. Currently there is only one workaround - the one pedro described.
I'll take this.
This is not calc specific since the code is in the shared framework. Changing the component accordingly.
Hi Eike, Is this someting that makes bells ring at your side (no alarm bells ;-) ) ? thanks - Cor
(maybe better ask mstahl ?)
Rarely used feature. Do the devs think it's priority be reduced?
(In reply to comment #14) > Rarely used feature. > > Do the devs think it's priority be reduced? Assigned, devs pay attention too it, and it actually blocks people opening certain files in LibreOffice. Indeed Annoying
Hmm, if you read the comment #7, it worked as expected only in LO-3.4 by luck. It did not work before and it is broken in LO-3.5 again. A proper solution might even need rework of the file type detection code. I agree with dE that it is less used feature and it does not belong to the most annoying bugs.
Ah, I have spoken with Cor on irc. I should have read the bug more carefully. It actually worked in earlier LO versions. Also it might affect quite some users. So, let's put it back in MAB. I am sorry for the mess. My main intention was to encourage dE to work for us.
According to comment #11, this issue is not Calc-specific, therefore changed Summary accordingly to prevent misunderstandings.
This will be fixed in 3.6.0. http://cgit.freedesktop.org/libreoffice/core/commit/?id=552bebe6fa27fa58d07d87283a4b24e6052ab3d4 Why this was not fixed sooner? Refer to my blog post. http://kohei.us/2012/05/21/what-goes-on-when-loading-a-file/ I don't know who designed this piece of code, but it's horrendously complex and very easy to break. It took me a few days to even start to understand the code, let alone come up with a "right" fix. Now, I really hope that's indeed the right fix (i.e. that won't cause regression), but to the best of my ability that's the best and most sensible thing we can do there. The real mystery is how this code ever worked before. The handling of pre-selected filter hadn't changed for ages.
Hi Kohei, (In reply to comment #19) > This will be fixed in 3.6.0. Ah wow! > http://kohei.us/2012/05/21/what-goes-on-when-loading-a-file/ I saw that few days ago. So indeed, tough piece to dive in. > Now, I really hope that's indeed the right fix (i.e. that won't cause > regression), but to the best of my ability that's the best and most sensible > thing we can do there. We'll ping people to do the tests :-) > The real mystery is how this code ever worked before. The handling of > pre-selected filter hadn't changed for ages. If you can't see any change, who can? May have been some change at a different level in the code?
(In reply to comment #20) > > We'll ping people to do the tests :-) He, I just see that the masterbuild I have, version 3.6.0alpha0+ Build ID: 1bb9a60 does contain the patch. Indeed works. Super!
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc9b4a29f1928fabcd4094942d32bc5985091838&g=libreoffice-3-5 rhbz#868953 fdo#45084 When the caller specifies filter type, stick to it It will be available in LibreOffice 3.5.8. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.