Bug 37024 - UI: WEB-View for Form layout no longer available
Summary: UI: WEB-View for Form layout no longer available
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.4.0 Beta4
Hardware: Other All
: high major
Assignee: Michael Stahl (allotropia)
Whiteboard: target:3.4.6 target:3.5.1 target:3.6....
Keywords: regression
: 41075 41161 41172 42733 44093 (view as bug list)
Depends on: 35661
Blocks: mab3.4 mab3.5
  Show dependency treegraph
Reported: 2011-05-09 09:43 UTC by André Schnabel
Modified: 2012-05-22 04:40 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:

database file with form (10.98 KB, application/vnd.sun.xml.base)
2011-05-09 09:43 UTC, André Schnabel
Form in Libo 3.3 (112.57 KB, image/png)
2011-05-09 09:47 UTC, André Schnabel
same form in LibO 3.4beta4 (101.07 KB, image/png)
2011-05-09 09:48 UTC, André Schnabel

Note You need to log in before you can comment on or make changes to this bug.
Description André Schnabel 2011-05-09 09:43:36 UTC
Created attachment 46488 [details]
database file with form

Database forms that were created in a former LibreOffice version look different when opened in LibO 3.4 beta4. Controls are now partially placed outside the form area.

Just open attached example using LibO 3.3 and 3.4 (or see screenshots). The biblio exaple connects tot he default biblio db.
Comment 1 André Schnabel 2011-05-09 09:47:59 UTC
Created attachment 46489 [details]
Form in Libo 3.3
Comment 2 André Schnabel 2011-05-09 09:48:30 UTC
Created attachment 46490 [details]
same form in LibO 3.4beta4
Comment 3 Alex Thurgood 2011-05-09 09:48:45 UTC
Confirming on Mac OSX. I have seen this problem before in a previous version of
OOo (possibly in the change from 2.x > 3.x ??, don't remember exactly). PITA.

Comment 4 Alex Thurgood 2011-05-09 09:49:38 UTC
Regression with regard to 3.3.2.

Comment 5 Alex Thurgood 2011-05-09 09:50:14 UTC
Nominate to 35673 ?

Comment 6 Zoltán Reizinger 2011-05-09 23:10:30 UTC
This is same as in OOo 3.4 beta, print/web layout problem in edit mode, see OOo bug 117545.
Comment 7 Alex Thurgood 2011-09-26 09:33:37 UTC
*** Bug 41172 has been marked as a duplicate of this bug. ***
Comment 8 Alex Thurgood 2011-09-26 09:35:31 UTC
There have been at least 2 reports on the English users mailing list as well regarding this problem, and I have seen at least one on the French users mailing list.

Comment 9 Drew Jensen 2011-09-26 09:37:19 UTC
*** Bug 41161 has been marked as a duplicate of this bug. ***
Comment 10 Rainer Bielefeld Retired 2011-09-26 10:20:42 UTC
[Reproducible] with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]", still a problem with
Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 81607ad-3dca5fd-da627d2)]"

With the newly only available form view "Printlayout" Forms created with LibO 3.3,. "WEB-View" is no longer available, both menu items in menu View are disabled. 

When I add icons "Weblayout" and "Printlayout" to a new toolbar they will be disabled, too (not unexpectedly)

I doubt that that has been intended.

OOo 3.3 does not show that problem

I saw you active in some UI bugs looking similar to me.
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 11 Noel Power 2011-10-10 01:44:43 UTC
(In reply to comment #10)
> @Noel:
> I saw you active in some UI bugs looking similar to me.
> Please feel free to reassign (or reset Assignee to default) if it’s not your
> area or if provided information is not sufficient. Please set Status to
> ASSIGNED if you accept this Bug.
well I don't really know anything about form and/or odb layout stuff. For the toolbar entries isn't this a separate problem that deserves it's own issue ( or perhaps I misunderstood the descriptions above )
Comment 12 Boudi 2011-10-10 03:07:26 UTC
I volunteer as a tester for base. To prevent this from happening again.
This problem indeed occurred earlier in OO, when going from 3.2 to 3.3.
Libo 3.4.3 is now standard with Ubuntu but still with this bug. This is quite annoying.
I offer clients to replace MS-Access with Libo Base. Clients (only 2 now) wait with migrating to new versions of LiBo and OO until I give the green light because of this experience.
Also the form-image embedded in the odt file looks bad.
I really would like to help making this better since a well working MS-Access replacement is a potential MS-Office killer.
Comment 13 m.michailowitsch 2011-11-16 04:50:43 UTC
LibreOffice 3.4.4 opens a database form always in print layout view instead in the Web layout view. But it does work in OOo.
Comment 14 Zoltán Reizinger 2011-12-12 23:53:06 UTC
*** Bug 41075 has been marked as a duplicate of this bug. ***
Comment 15 Alex Thurgood 2012-01-04 08:52:07 UTC
*** Bug 44093 has been marked as a duplicate of this bug. ***
Comment 16 Michael Stahl (allotropia) 2012-01-23 12:08:37 UTC
looks like there are 2 problems here:
- form doesn't open in web mode
  this is fixed by the patch attached at issue 117545,
  which is already in libreoffice-3-5 and master.
- the form area is smaller:
  in OOo 3.3 the height is about 25 cm,
  while in OOo 3.4 beta and LO 3.4+ it is only ~20cm
Comment 17 Drew Jensen 2012-01-23 12:21:30 UTC
Well, the print view vs web view problem is still there in 3.5 RC1.

Found a workaround:

Open a writer document window 
Switch to Web view
Close the writer document window (no need to save anything)
From here out the problem is gone with any Base forms for the duration of the current LibO session.
Comment 18 Michael Stahl (allotropia) 2012-01-23 13:29:01 UTC
the form opens in Web layout when it is edited,
but if you use "open" i'm not sure because it's
not displayed in the menu.

the code in dbaccess only requests the Web layout
for editing; it doesn't do anything special for open.

do you think that "open" should also use the Web layout?

actually i just set a breakpoint in SwRootFrm::CheckViewLayout,
which is hit several times during opening the document, and
always the BROWSE_MODE is set, so that seems to work.

about the page size problem: the forms/Obj11/styles.xml has this:

 <style:page-layout style:name="Mpm1">
  <style:page-layout-properties fo:page-width="29.7cm" fo:page-height="21.001cm" 

apparently OOo 3.4 now uses the page size of the page style
even in Web layout, while OOo 3.3 did not.

the workaround is simply to set a larger page size via Format->Page.

i'm not familiar with this forms stuff:
is it wrong to respect the page size for forms?
Comment 19 Drew Jensen 2012-01-25 23:30:00 UTC
Should 'open' use web view - YES

Should a form respect the page size - NO if in web view, yes if in print view

Another good example of how this affects:

Use the form wizard to create a form in any layout other then table control, with more then a few fields. The wizard lays it out in web view, but then switches to print view - in most cases this will cram those controls that fall past the right margin over top of other contols (and labels)..it's a real mess.
Comment 20 Boudi 2012-01-28 05:28:54 UTC
Until this issue is resolved I can not advice users to go from to 3.3 to 3.5.
As I had to advice to stay on 3.3 when 3.4 was released.
Drew Jensen is 100% right in the last comments.

A pity because 3.5.0rc2 resolved a lot of other issues.

odt files with webview=true (embedded on odb or not) should open in webview and in there (own) last saved size. Not in the size of any last saved document.
Comment 21 Alex Thurgood 2012-01-28 08:19:19 UTC
(In reply to comment #20)

Yes, it is one of the few remaining Base blockers in the 3.4 line and still present in the 3.5 line. I will add it to the 3.5 blockers as well.

Comment 22 Alex Thurgood 2012-01-28 08:21:09 UTC
Added to 3.5 Most Annoying bugs
Comment 23 Michael Stahl (allotropia) 2012-01-30 12:47:09 UTC
i think i've tracked down the second problem now.

while SwDoc thinks it's in web layout mode,
the view actually thinks it's in print layout mode
(as seen by setting a breakpoint in SwPageFrm::SwPageFrm).

the reason for that is that there is some obscure mbLoaded flag
at the SwDoc, and that is not set because we hit a condition
in SwDoc::SetAllUniqueFlyNames() that prevents it.

there is a new check for the flag in SwView::SwView that
connects this flag with the web layout mode/BROWSE_MODE,
whose purpose is completely unclear to me.

this came in with ebc5777548dea42ed966a16c66d879b1485bbfb4,
first commit from CWS swlayoutrefactoring.
Comment 24 Michael Stahl (allotropia) 2012-02-02 07:46:47 UTC
fixed on master:
Comment 25 Lionel Elie Mamane 2012-02-06 05:19:54 UTC
Reopening so that it does not show up as fixed in "most annoying".
Comment 28 Boudi 2012-02-09 00:05:51 UTC
Thanks a lot!
Comment 29 Michael Stahl (allotropia) 2012-05-22 04:40:48 UTC
*** Bug 42733 has been marked as a duplicate of this bug. ***