[ADFEMG-56] Enable User Customizations across Sessions using MDS can break popups Created: 11/Sep/12  Updated: 06/Feb/13  Resolved: 06/Feb/13

Status: Closed
Project: adfemg
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ulrich Gerkmann-Bartels Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive sample.mds.zip    
Tags: mds

 Description   

Environment

  • JDeveloper/ADF version : 11.1.2.0 - 11.1.2.2
  • WebLogic Server version : n.a.
  • impact level : HIGH
  • why : break popup interaction

Summary

Enable User Customizations across Sessions using MDS.

See [blog http://maybe-interesting.blogspot.de/2012/09/again-enable-user-customizations-across.html] for detailed description and screenshots.

Steps to reproduce

  • Create a application with af:popup and af:table
  • Enable User Customizations across Sessions using MDS
  • Run ADF App
  • Scroll down the table
  • Try to open the popup

Occured result/behaviour

  • popup don't open
  • in the top left you can see a little white box

Expected result/behaviour

  • Enable User Customizations across Sessions using MDS should not have negative impact on the application.

Testcase

Further information



 Comments   
Comment by chriscmuir [ 14/Sep/12 ]

Ulrich, presumably if you're using the "Enable User Customizations" feature with "Across Sessions using MDS", you must have an MDS repository setup and running with the application.

Can you confirm please you've tested this issue against a full blown MDS setup? I'd like to confirm this before submitting the bug.

Comment by Ulrich Gerkmann-Bartels [ 14/Sep/12 ]

Until now i have not use a Database Repository.
The test case use the out-of-the-box File Repository with the integrated WLS.

Comment by chriscmuir [ 17/Sep/12 ]

Right, so to be clear on my part when I write up the steps to reproduce this, besides changing the db connection and running the page, there's no other setup required to get the file repository MDS working ya? (as you say, it should work out-of-the-box)

Comment by Ulrich Gerkmann-Bartels [ 17/Sep/12 ]

Yes !

Comment by chriscmuir [ 18/Sep/12 ]

I appreciate answering these questions may be tedious, but as I have to lodge the bug on your behalf and I get all the emails back from Support/developers rather than yourself, I want to make sure I have enough detail for the bug to proceed without constant questions coming back to me from internal Oracle staff.

I've lodged bug 14638726. If the bug is critical to your organization please lodge an SR with Oracle Support referencing this bug.

For faster turn around and to make my job easier in the future, please list as I've done in the bug the steps to reproduce the issue.

Regards,

CM.

Comment by Ulrich Gerkmann-Bartels [ 18/Sep/12 ]

Hi Chris,

I try my best to bring a simple test case to show the issues.

We open a SR 3-6166058128 and get following fix:

Change

<af:popup childCreation="deferred"
autoCancel="disabled" id="p1"
contentDelivery="lazyUncached">

to

<af:popup childCreation="deferred"
autoCancel="enabled" id="p1"
contentDelivery="lazyUncached">

(Bug 11057528 (RICHPOPUP CONCURRENCY ISSUES WHEN USER CUSTOMIZATION IS ENABLED)

thx,

ulrich

Comment by Jan Vervecken [ 19/Sep/12 ]

fyi

In bug 14638726, "AF:POPUP RENDERS INCORRECTLY FIRST TIME WITH MDS TURNED ON", I noticed a comment referring to online docs for af:popup (and it also seems to repeat section "Controlling Aspects of Auto-dismissal" [1] about the autoCancel property)

And ending with ...

*** 09/19/12 02:24 am ***
...
As such it appears this could be the cause, though the docs don't mention MDS 
as one of the causes.  
 
The workaround from bug 11057528 appears to be to set autoCancel=enabled.  
 
Is it correct to say MDS is another limiting factor on autoCancel=disabled, 
and if yes, are you happy for this bug to be closed and another doc bug to be 
raised so this limitation is documented?

Also, bug 14638726 currently has "Status 32 - Not a Bug. To Filer".

  • (q1) Which is the documentation bug number about mentioning MDS as one of the causes?

(By the way, Chris, the bug note above has significant information (luckily published) without being labelled with "REQUEST TEXT", "DISCUSSION" or "RESPONSE" as you suggested in ADFEMG-58 [2].)

regards
Jan Vervecken

Comment by chriscmuir [ 06/Feb/13 ]

Customer on bug 11057528 has agreed to close the issue with workaround. Closing this issue out as a result.





[ADFEMG-53] Enable User Customizations across Sessions using MDS can break ADF Application Created: 03/Sep/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Closed
Project: adfemg
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ulrich Gerkmann-Bartels Assignee: duncanmills
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive sample.mds.break.ui.zip    
Tags: mds

 Description   

Environment

  • JDeveloper/ADF version : 11.1.2.0 - 11.1.2.2
  • WebLogic Server version : n.a.
  • impact level : HIGH
  • why : break complete user interface interaction

Summary

Enable User Customizations across Sessions using MDS.

See blog post for detailed description and screenshots.

Steps to reproduce

  • Create a application with af:forEach and af:accordion for dynamic UI
  • Enable User Customizations across Sessions using MDS
  • (Optional) Deactivate all persistent options for showDetailItem
  • Run ADF App
  • Try to open the accordion several times

Occured result/behaviour

  • after some clicks the ui freeze and must be refreshed

Expected result/behaviour

  • Enable User Customizations across Sessions using MDS should not have negative impact on the application.

Testcase

Further information



 Comments   
Comment by duncanmills [ 04/Sep/12 ]

My suspicion here would be specifically aimed at the use of af:forEach within the accordion - checking this out.

Comment by duncanmills [ 04/Sep/12 ]

Right I've done some digging in this.
We started to support the persistence of items within iterators and forEach in 11.1.2+ So that probably has a bearing on this.
Running in Chrome I can observe the following:
1) If I run without 'Enable User Customizations' when it works OK
2) If I run with 'Enable User Customizations' but only for the duration of the session it works although the response on the disclose seems a little sluggish
3) If I run with 'Enable User Customizations' Across Sessions then the first disclose does not quite fail - there is a slight UI change but the detail is not shown. Subsequent disclose attempts generate a JavaScript error "Unexpected panelAccordion showDetailItem disclosure state for queueing client events" If you then refresh the page then it starts to function.

Comment by duncanmills [ 04/Sep/12 ]

OK I think I've got to the bottom of this and it's simple to fix. The root of the issue here is a difference in behaviour between JSP and Facelets as a page technology.
The JSP engine has some hacks in it to prevent duplicate IDs in the case of a forEach loop. Facelets does not so you have to be careful.
The solution in your example is to either:
1) Remove the ID attribute from your showDetailItems and let JSF generate them.
or
2) Amend the ID attribute to something like: <af:showDetailItem id="sdi3_#

{accord.index}

" ... to ensure a unique id

This will ensure that every instance of the showDetail has a unique ID.

Give that a go...

Comment by Ulrich Gerkmann-Bartels [ 04/Sep/12 ]

Great - i try (2) and i can confirm it works

Comment by duncanmills [ 04/Sep/12 ]

This is down to the behaviour of unique ID generation (or not) within the scope of forEach loops.
See: https://blogs.oracle.com/groundside/entry/foreach_and_facelets_a_bugfarm

Comment by Jan Vervecken [ 04/Sep/12 ]

Thank you for the insights Duncan.

As you write in your blog post [1]

  • (st1) "... JSF under JSP implements some hacks ... to transparently fix this problem for you ..."
  • (st2) "... when running with Facelets ... JSF does not mess around in the background for you ..."
  • (q1) Are both (st1) and (st2) intended behaviour?

It seems strange that for a given af:forEach the run-time behaviour can be so different.
Or is this covered by the af:forEach tag documentation [2] saying
"Note: this tag is not supported in Facelets, because c:forEach is fully functional in Facelets."

regards
Jan Vervecken

Comment by duncanmills [ 04/Sep/12 ]

There is no need to use af:forEach in facelets because c:forEach works correctly. Note that af:forEach was only created in the first place because of shortcomings in the JSTL version.
However, af:forEach does still function and I think that it actually just uses c:forEach internally anyway.
The actual problem here is discussed in the JavaServer Faces issues repository (it's a JSF issue not an ADF issue): http://java.net/jira/browse/JAVASERVERFACES-1527, as you see it's the same for both af: and c:forEach





Generated at Sat Feb 28 21:56:07 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.