In(Sanity) Testing Mondays

[Kevin Rushforth]

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:
https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PST until 1pm 
PST.


Happy testing!

Thanks.

-- Kevin

8u-dev and 9-dev repos are unlocked [was: OpenJFX 8u-dev and 9-dev repos will be locked on Friday for maintenance]

[Kevin Rushforth]

The repo maintenance is done and the 8u-dev and 9-dev repos are unlocked.

-- Kevin


Kevin Rushforth wrote:
The following OpenJFX repos will be locked tomorrow (Friday) for some 
maintenance:


9-dev/rt
9-dev/tests
8u-dev/rt
8u-dev/tests

Please consider them as read-only mode during the lockout period.

Start time:  07:00 Pacific, Friday, 2016-06-24
End time:  ETA is 13:00 Pacific, but I will send an explicit "all 
clear" message when the maintenance is over


If someone forgets and pushes a changeset during that time, it might 
get lost.


This should not affect the ability to clone or pull during that time 
(or if it does it will only be transiently).


-- Kevin

Re: Reentrent call to Control.createDefaultSkin()

[Tom Schindl]

Hi,

I filed https://bugs.openjdk.java.net/browse/JDK-8160242

Tom

On 23.06.16 00:55, Jonathan Giles wrote:
> I think this is a reasonable expectation. Can you please file an issue
> and we can progress it from there?
> 
> Thanks,
> 
> -- Jonathan
> 
> On 23/06/16 7:31 AM, Tom Schindl wrote:
>> Hi,
>>
>> Take a look at the stack below.
>>
>>> ComboBoxListViewSkin(ComboBoxBaseSkin).(ComboBoxBase,
>>> ComboBoxBaseBehavior) line: 57   
>>> ComboBoxListViewSkin(ComboBoxPopupControl).(ComboBoxBase,
>>> ComboBoxBaseBehavior) line: 61   
>>> ComboBoxListViewSkin.(ComboBox) line: 113   
>>> ComboBox.createDefaultSkin() line: 420   
>>> ComboBox(Control).impl_processCSS(WritableValue) line:
>>> 859   
>>> FSimpleSelectControl(Parent).impl_processCSS(WritableValue)
>>> line: 1280   
>>> FSimpleSelectControl(Control).impl_processCSS(WritableValue)
>>> line: 855   
>>> FlexibleGridLayoutPane$LayoutItem(Parent).impl_processCSS(WritableValue)
>>> line: 1280   
>>> GridPane(Parent).impl_processCSS(WritableValue) line: 1280   
>>> FlexibleGridLayoutPane(Parent).impl_processCSS(WritableValue) line:
>>> 1280   
>>> VBox(Parent).impl_processCSS(WritableValue) line: 1280   
>>> ScrollPaneSkin$4(Parent).impl_processCSS(WritableValue)
>>> line: 1280   
>>> ScrollPaneSkin$3(Parent).impl_processCSS(WritableValue)
>>> line: 1280   
>>> ScrollPane(Parent).impl_processCSS(WritableValue) line: 1280   
>>> ScrollPane(Control).impl_processCSS(WritableValue) line: 855   
>>> ScrollPane(Node).processCSS() line: 9056   
>>> SimpleListCell(Node).applyCss() line: 9153   
>>> ComboBoxListViewSkin(ComboBoxBaseSkin).updateDisplayArea()
>>> line: 150   
>>> ComboBoxListViewSkin.updateButtonCell() line: 406 [local variables
>>> unavailable]   
>>> ComboBoxListViewSkin.(ComboBox) line: 134   
>>> ComboBox.createDefaultSkin() line: 420   
>>> ComboBox(Control).impl_processCSS(WritableValue) line:
>>> 859   
>>> FSimpleSelectControl(Parent).impl_processCSS(WritableValue)
>>> line: 1280   
>>> FSimpleSelectControl(Control).impl_processCSS(WritableValue)
>>> line: 862   
>>> FlexibleGridLayoutPane$LayoutItem(Parent).impl_processCSS(WritableValue)
>>> line: 1280   
>>> GridPane(Parent).impl_processCSS(WritableValue) line: 1280   
>>> FlexibleGridLayoutPane(Parent).impl_processCSS(WritableValue) line:
>>> 1280   
>>> VBox(Parent).impl_processCSS(WritableValue) line: 1280   
>> It shows you a stack where I create an instance of a ComboBox but this
>> code creates 2 Skin-Instance for the same ComboBox-Instance (the 2nd
>> iteration starts with updateDisplayArea).
>>
>> I've been unable to come up with a stripped down example but I think
>> Control#impl_processCSS(WritableValue) has to ensure that no
>> 2nd skin is created while the first initialization is not finished.
>>
>> Something like that:
>>
>> private boolean createSkinCreationInProgress;
>>
>> @Override protected void impl_processCSS(WritableValue unused) {
>>>  super.impl_processCSS(unused);
>>>
>>>  if (getSkin() == null) {
>>>  if( createSkinCreationInProgress ) {
>>>  return;
>>>  }
>>>  try {
>>>createSkinCreationInProgress = true;
>>>  // try to create default skin
>>>  final Skin defaultSkin = createDefaultSkin();
>>>  if (defaultSkin != null) {
>>>  skinProperty().set(defaultSkin);
>>>  super.impl_processCSS(unused);
>>>  } else {
>>>  final String msg = "The -fx-skin property has
>>> not been defined in CSS for " + this +
>>> " and createDefaultSkin()
>>> returned null.";
>>>  final List errors =
>>> StyleManager.getErrors();
>>>  if (errors != null) {
>>>  CssError error = new CssError(msg);
>>>  errors.add(error); // RT-19884
>>>  }
>>>  Logging.getControlsLogger().severe(msg);
>>>  }
>>>  } finally { createSkinCreationInProgress = false; }
>>>  }
>> }
>>
>> Does that make sense?
>>
>> Tom
>>
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: Posible bug when maximizing an already maximized stage on Mac

[Tom Schindl]

Hi,

I filed https://bugs.openjdk.java.net/browse/JDK-8160241 . As this is a
very serious bug rendering applications completely unusable on OS-X I
hope it gets some attention.

Tom

On 23.06.16 15:32, José Pereda wrote:
> No, I didn't. It didn't get much of attention.
> 
> You can go ahead.
> 
> Jose
> 
> On Thu, Jun 23, 2016 at 3:15 PM, Tom Schindl
> > wrote:
> 
> Did you ever filed a bug for that? This is a serious bug rendering
> JavaFX applications useless.
> 
> Tom
> 
> On 31.03.16 11:16, José Pereda wrote:
> > Hi all,
> >
> > Running this little test on a MacBook Pro Retina, OS X 10.11.4,
> with JDK
> > 8u77:
> >
> > @Override
> > public void start(Stage stage) {
> > Button button = new Button("Click to maximize");
> > button.setOnAction(e -> stage.setMaximized(true));
> > Rectangle2D bounds = Screen.getPrimary().getVisualBounds();
> > stage.setScene(new Scene(new StackPane(button),
> bounds.getWidth(),
> > bounds.getHeight()));
> > stage.show();
> > }
> >
> > which shouldn't do anything at all, since the stage is already
> maximized,
> > turns into an iconified application, with root dimensions 0x0, stage
> > dimensions 0x22 (height of menubar), stage.isIconified() returns
> false, and
> > it can't be restored again to any visible size by any means other than
> > closing the application from the dock.
> >
> > A posible situation where this could happen: persisting and
> restoring the
> > properties (x, y, width, height and maximized) of a maximized stage.
> >
> >
> > I haven't found any report of this. Should I file a bug?
> >
> > Thanks,
> > Jose
> >
> > --
> >
> 
> 
> --
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> 
> 
> 
> 
> -- 
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

[9] Review request for 8146211: WebView can't alert from a timer

[Murali Billa]

Hi Kevin, Arun,

Please  review below fix:


JBS : https://bugs.openjdk.java.net/browse/JDK-8146211
Webrev : http://cr.openjdk.java.net/~mbilla/8146211/webrev.00/


Thanks, 
Murali