1299165 - Opening/viewing reports in Peoplesoft no longer displays output after Firefox updated to v.48; now just blank page

Status: RESOLVED DUPLICATE of bug 1292522

(Firefox :: Untriaged, defect)

Description

[Denise]

Attachment: FFv48_PSoft.docx -- before and after FF v.48

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160823121617

Steps to reproduce:

In Peoplesoft Financials go to Purchase Orders, select a PO, click on Print button to display to screen. 






Actual results:

Since users' workstations' FireFox auto-upgraded to v48, the display is blank.


Expected results:

should display PO report.

Comment 1

[:Gijs (out for now; he/him)]

Not a security bug.

Can you do the following, please:

when you select a PO, before clicking 'print', use:

ctrl-shift-j

this will open up Firefox's Browser console, which logs errors and the like. You can clear it to get rid of anything that's already there using the button with a bin/trashcan on it.

then click 'print' to open up the print tab (which is displaying blank).

What shows up in the browser console, if anything?


Separately, do you or peoplesoft have a test instance that we can reproduce this problem in? Have you reported this to Peoplesoft? What version of their software are you running?

Comment 2

[Denise]

Opened FF console when clicked on Print button and it showed property access error -- see attached Firefox_48_console_clickPRINT.docx

I have opened case w/Oracle-Peoplesoft, but since this only occurs in FF v.48, their position is that it's not Peoplesoft.

Am running Peoplesoft Financials 9.0 on Peopletools 8.54. There have been no recent changes to the environment.

Comment 3

[Denise]

Attachment: console view

Comment 4

[:Gijs (out for now; he/him)]

Thanks! Your initial attachment blocks out the browser URL bar, so I don't know the URLs where these pages are running. Can you provide the URLs, or if you prefer not to, can you clarify if either or both the purchase orders screen and the screen that pops up when you click the print button have URLs that include a port number, and if so, which does/doesn't, and if they are the same?

Alternatively, can you try a build from https://www.mozilla.org/en-US/firefox/channel/#beta and let us know if the problem occurs there?

This looks like it's bug 409885, which has a fix in 49 (current beta). bz/dragana, anything else that would be helpful here?

Comment 5

[Dragana Damjanovic [:dragana]]

This is probably dup of 1292522. It should work on beta.

Comment 6

[Denise]

Many thanks!

The beta version works fine -- both queued page and .pdf now display again.

fyi: I checked the url/port #s for both pages:  same host:port for both.

When will v.49 (non-beta) be available?

Comment 7

[:Gijs (out for now; he/him)]

(In reply to Denise from comment #6)
> Many thanks!
> 
> The beta version works fine -- both queued page and .pdf now display again.

Yay!

> fyi: I checked the url/port #s for both pages:  same host:port for both.

Hm. Does either of these pages have iframes that don't (have the same host:port), or something? I'm a bit confused about how the app was affected by bug 1292522 if the domains and ports are all the same (and, for that matter, why the code is using document.domain if the host + port are the same everywhere). Anyway, might be moot if this is fixed in 49.

> When will v.49 (non-beta) be available?

Around the 13th of September. It may take longer for automatic updates to kick in, but you should be able to download builds from that point. Trying to get an update (dot-release) for 48 before then is likely not feasible, so I think this can then probably be duped to bug 1292522, as there isn't much left to do here. I'll leave that to bz and/or dragana.

Comment 8

[Denise]

Thanks for the info.

I had originally checked only the host:port displayed in the URL in browser after process completed. Dug deeper and found that the Print action calls to a Peoplesoft REN web server -- same host but different port -- which then redirects back to session (same port as original page). 

So yes, a different port to process and display the PO.

Again, many thanx!

Comment 9

[:Gijs (out for now; he/him)]

(In reply to Denise from comment #8)
> I had originally checked only the host:port displayed in the URL in browser
> after process completed. Dug deeper and found that the Print action calls to
> a Peoplesoft REN web server -- same host but different port -- which then
> redirects back to session (same port as original page). 
> 
> So yes, a different port to process and display the PO.

Ah, mystery solved! Many thanks. In this case, duping to 1292522 to keep track of it all in one place.