FLUID-6178: fluid.prettyPrintJSON fails to properly guard against exploding synthetic properties

Metadata

Source
FLUID-6178
Type
Bug
Priority
Major
Status
Closed
Resolution
Fixed
Assignee
Antranig Basman
Reporter
Antranig Basman
Created
2017-08-02T18:22:59.675-0400
Updated
2024-07-22T09:04:50.247-0400
Versions
N/A
Fixed Versions
N/A
Component
  1. Framework

Description

Our fluid.prettyPrintJSON utility, used notably within the fluid.js fluid.renderLoggingArg monkey-patch which is used in the node environement, has code which attempts to guard against triggering synthetic properties which throw, but which is not completely effective.

In the pull request https://github.com/GPII/universal/pull/515 for GPII-2333, Steve Grundell triggered a collateral failure in a test case as a result of issuing the configuration

fluid.logObjectRenderChars = 0xffffff

This caused enough of an Infusion component to be rendered as a result of a fluid.describeActivity dump in the case of an expected test case failure that it tried to render a node "IncomingMessage" request object which had a faulty synthetic property for which the definition read

defineGetter(req, 'protocol', function protocol() {
  var proto = this.connection.encrypted
    ? 'https'
    : 'http';

In the case connection is not set, this property will throw on read access. We end up triggering this because the implementation of fluid.prettyPrintJSON invokes fluid.keys, which as the implementation comment indeed notes, "is not as clever as we think it is" and ends up unnecessarily evaluating all the values as well as the keys.

We can just replace this with Object.keys() which has been supperted in JS since IE9 - we may as well deprecate fluid.keys() whilst we are at it.

Comments